As part of my investigation into all things Microservice and Cloud Nativish I’ve been interviewing folk and have bags of interesting case studies and observations to share.
The first interview I’m going to talk about is the closest to home - Container Solutions (CS), which was formed in 2014 to provide specialist analysis and engineering around the new technologies of microservices, containers and orchestrators. At around the same time CS came into existence the term “Cloud Native” first started being bandied about, so it was interesting to hear how they’ve seen the market change in the past few years.
Banksy - Erokism If you care about security listen in to Sam Newman on Thursday!
Since they came into being one of Container Solutions’ main activities has been reviewing production Cloud Native or Microservice systems and providing feedback on best practice and next steps. According to the CTO Pini Reznik, Microservice and Cloud Native users have changed a lot in the past few years. “Two or three years ago businesses mostly fell into one of two groups. On one side you had companies who had barely heard of microservices and containers. On the other, you had experts who were experimenting heavily or even building in production. These folk invested significantly, usually with board level buy-in, and created systems for themselves with little or no help. Those were the companies we all learned from.” Pini’s view matches with what I’ve seen, there are quite a few enterprises who’ve been at this stuff for years but the tools were poor so it required loads of commitment from the whole company. They often had to build their own tools and platforms. Even their own clouds!
Recently, however, things have changed. According to Pini and his team, it’s now common for companies to start experimenting with Cloud Native technologies and microservices with low investment, i.e. cheaply in a bottom-up fashion. This is often initiated by a keen internal technical champion, usually a developer who was inspired to try containers or microservices by a meetup or a conference. Reznik says, “Once this person starts playing with the technology internally other engineers see the attraction, particularly for faster software delivery. They run more experiments, get excited and often decide to try bigger projects”. Getting from maverick developer to wider acceptance within a company is easier now. There’s better industry awareness of Cloud Native and microservices. Tech leaders hear conversations about it and see market support, it’s no longer such a scary, radical approach. You no longer need to make your own tools before you can start.
Unfortunately, it’s at this point that things can apparently go wrong for new users. Ironically, a common issue is that there’s loads of great stuff you can do with Cloud Native. All have potentially big benefits, but most are tough to deliver with lots to learn.
“Companies regularly approach us to say they’ve tried Cloud Native or microservices but it failed to deliver. The project became stuck”, says Reznik. “We saw a pattern emerge - as they became more aware of all the possibilities of Cloud Native and microservices they found it hard to focus on any one thing. But this is still hard tech so if they didn’t focus they got bogged down on every front”.
Pini and his engineers usually help by encouraging the tech teams to step back and prioritise. There are often plumbing tasks, like minimal automated testing or automating the build pipeline, that in CS’s experience make later tasks easier. “Companies often have a sensible wish list, but we find that the order you deliver features in has a huge impact on the success of the project. We advise teams to plan their build so that the project bootstraps itself, i.e. build a minimal base platform that immediately contributes to its own evolution.” In other words, he says “use the platform to develop the platform.”
CEO Jamie Dobson is even more assertive on the subject. “With Cloud Native, if a team isn’t getting modest ROI quickly they’re probably doing it wrong. A successful implementation should immediately start making further development easier and you can build steadily from there. If that’s not the case, they need to stop and step back. In our experience, they’re probably doing too much, too soon without a firm enough foundation”.
In Container Solution’s experience the driver for Cloud Native in most companies now is speed of delivery. Often companies start with microservices or containerisation. However, testing, diagnostics and automated builds are also vitally important - even more so than in a Monolithic system. If those basic hygiene factors are missing the project will suffer.
So, their conclusion is that the microservice and container market is no longer polarised between super-experts and almost total unawareness. Now that tooling has improved and toolchain and platform leaders have started to emerge a new group of companies are starting to try out this stuff tentatively, but often with a clear goal in mind or problem they want to solve. According to Dobson, “Cloud Native is no longer just the domain of trendy startups and banks with deep pockets”.
That’s all great, but the mechanisms behind this change are particularly interesting to me. The most important improvement in the sector over the past few years seems to be in the quality of the off-the-shelf plumbing tools (container engines, orchestrators, cloud, infrastructure management). What’s clear is that getting this right is crucial, and its success is measured by how invisible it becomes. My next case study will be on an implementation I was closely involved in as part of an early stage startup, which did extremely well in some areas of Cloud Native but less well in others. What can we learn from that?
Read more about our work in The Cloud Native Attitude.
Previous article
