Virtual Coffee With NearForm Director of DevOps, Alex Knol

Alex has lived an interesting life. Born in Holland, he lived a little while in North Carolina. Upon moving back to Europe, he desired a warmer climate, so he and his wife moved to a property a few kilometers outside of a small Spanish town, overlooking the Mediterranean.  Now, Alex lives completely off the grid, with all of the energy needs for his family of five coming from solar power. They use solar power even to pump their water from a well and they generate enough to have all the mod cons and appliances any household would need. Alex studied electrical engineering, and he built their entire off-the-grid system, including continually running performance apps. A master of understatement, he told me, “So I kind of just knew how to do all that stuff.”

We work closely in multidisciplinary teams, working as one with the Experience Architects and Technical Directors at NearForm, to create solutions for clients. I typically take care of some of the infrastructural platform parts of it.

As cross-functional teams, we share, with the client’s permission, lessons across different projects. We have ten people in DevOps at NearForm - in NY, Sweden, Prague and Dublin - and we try to get together as much as possible, even for a 15-minute sync, to talk about the things we do. It generates new insights because technology is evolving all the time and so quickly. It’s so important to share the burden of acquiring all this knowledge and these capabilities. It’s impossible to know it all as one single individual. This way, we can absorb knowledge from one another.

Traditionally there are lots of silos in companies. In technical solution delivery, you could have a development team with designers that is separate from teams in operations, information security, testing and so on. DevOps is about integrating all those parts. It’s the responsibility of the DevOps person to be part of that end-to-end architecture conversation, taking into account that the solution in development has to be ultimately deployed somewhere and making sure things get done right the first time.   I actually think “Platform Engineer” would be a better title for a DevOps Engineer.

It’s kind of like shifting left - shifting all the tasks that used to be done after the build was finished into the development process and as early as possible in the life cycle. But modern software development is no longer a linear process, it’s a continuous looped process. So really DevOps is about continuous integration, continuous development, continuous testing.

Many people think DevOps is just about automation, but it’s more about culture. It’s a way of working - working in a more seamless and integrated way.

Readiness, liveness.  Letting the surrounding of a service know that you are ready to take requests. You connect to your database or cache - whatever you need to do to be operational - and show the outside world that you are ready for requests.

And logging. Logging should be ubiquitous to developers, they shouldn’t have to know where they are going. Let the platform take care of that for you.

Google Cloud, Azure, AWS – they all work differently. But the same principles apply: remove all the friction from later in the process and address it early on.  Typically things become cheaper that way.

No DevOps is the foundation of the building and the wireframe would be kind of like the blueprint.

You’d lay a completely different foundation if you were building a three-story building, than a 35-storey skyscraper. The foundation is your production run-time, that’s what it actually has to stand on for the next 50 years. Software always lives a lot longer than what is envisaged at design time – look at most of the banking systems for instance.   In physical architecture the foundation is an integral part of the building, and so should your production deployment be when you’re designing software.

The way that we have built NearForm on open source, and we always give back to that open source community – I think that’s rare and it makes us unique.

Sometimes we’re called in to do the automation after the software solution is built, and the client is looking to deploy it in a modern, cloud-native way. Sometimes they’re asking us to help them design an architecture from the start, in a cloud-native way.  This is where we like to add real value.

Going cloud-native - whereby the application’s entire lifecycle exists on a cloud platform - allows an IT organisation to use automation, and by extension DevOps, to reduce time to market. It also lowers costs as you don’t need to keep the entire infrastructure park online all the time.  You can use automation tools to scale apps and services more fluidly. And for this, there is a lot of technical stuff like Kubernetes – an Open Source container management platform designed by Google - that can greatly reduce the operational and security risk of massive failures by packaging of applications into smaller, more manageable chunks. This also improves agility and response times.

Finance, business consulting, travel and technology. One of the most interesting projects I recently worked on was an automated benchmarking pipeline for a client in the technology sector. They wanted to know the impact of code changes on the performance of their networking transport system.

So we built a benchmarking infrastructure to provide their development team with graphical data on how their commits would affect the performance of libraries in various areas in their stack.  We’re running Clinic.js , our node.js performance tool, automatically on all these libraries and the results are presented in a dashboard in visual format. The tool really gives a picture of the performance of your stack and what the slowest parts are so that teams can take corrective action.

The aim is two-fold, one to increase performance, but the other is to give them feedback quickly if their commits or changes that they’ve committed have adverse performance effects. Someone could be working on an unrelated area and do a commit that has enormous performance implications.

That’s true but it is also around the speed at which we deliver new end-to-end solutions that can be scaled and are flexible.  Our sweet spot is around building a first version of an app or service and then delivering an MVP – one that can be used and has actual value but also be scaled up to be ready for primetime. It’s built in such a way that it can be extended and integrated easily. The same goes for the platform we put underneath it. It’s flexible and based on industry standards so that it’s relatively easy to put into a fully scaled, production-ready form.

The way that we have built NearForm on open source, and we always give back to that open source community – I think that’s rare and it makes us unique.

We do some of that through leading by example, in how we collaborate and co-create with clients and their stakeholders as one team and in how we adopt a fail-fast approach to innovation, all the while transferring knowledge and skills inhouse. It’s also that we help organisations build a community around what they’re doing – doing new things with existing and new technology. We’re a big part of node.js and the community around that. NearForm can help a company mature in their journey to adopting new technology, and finding a community and people around it.

Companies want to be cloud-native. A big difference about NearForm is that we’re remote-native.

A big difference about NearForm is that we are actually remote-native . Most companies that allow remote working, only doing it half measure.  What happens there is that things go on when the camera is off and those that are remote miss out - even if it is just the water cooler moments.

Being a remote-native company, you instinctively know not to discuss anything important when the camera is off. NearForm does that really well, everybody is remote working and so all the important conversations happen when the camera is on.

Yes, where I live with my family in Spain is very rural. We live on a hill and we overlook a huge rice delta, where we get to see all the colours of the rice fields changing through the seasons. It’s a slower pace of life. When I travel to NearForm, and go through Dublin, it all feels like a lot…. people, noise, cars and buses ...there's a lot going on!

Also, I’m into mountain biking. It’s so nice to go for my bike rides during lunch, especially because in the winter it’s too dark to do it before or after business hours. That kind of flexibility is accepted at NearForm.  As long as you have a stable internet connection – and you’re good at what you do – you can work for NearForm. It’s a trust thing ingrained in the company culture and it works really well. That opens up the world as our resource pool.

I will have to say DevOps.com obviously - I am an author for the site. It’s practical, hands-on and AWS focused and it’s run by people considered the founders of DevOps, people like John Willis and Gene Kim. And there are lots of interesting blogs – Giant Swarm , Rancher , neuVector and Medium .

*** Many thanks to Alex for his views on DevOps as the necessary foundation for a lasting structure and how tools like Clinic.js can help to identify and solve performance bottlenecks.  It’s also great to hear how a remote-native working model can really help deliver positive lifestyle changes.