Container Solutions: Cloud Migration with the Best Tools — and the Right Culture
Container Solutions believes that an organization’s internal culture is just as important as its technology when it comes to making a successful, not to mention effective, migration to the cloud.
With an emphasis on open source container and microservices solutions, Container Solutions brings experienced real-world evaluation, implementation and training to enterprises poised for transformation into Cloud Native entities. The company delivers software engineering services, with microservices and container-based development, from four locations across Europe (and, very soon, Canada).
Arguably, this company’s unique value is working closely with clients on a highly individualized cultural level. Co-founder and CEO Jamie Dobson believes that client enterprises must imbue themselves with the philosophies and practices essential to success as a cloud-native organization. The New Stack caught up with Dobson, along with Container Solutions’ CTO and co-founder Pini Reznik, to talk about the current state of cloud-native strategy and technologies, and how companies might take advantage of them to deliver applications and services at high velocity.
“Creating small services that do one thing well is all the rage right now but it is simply good software engineering — and a sound philosophy to build a company around,” — Jamie Dobson
First, the Container Solutions backstory: Container Solutions was born in 2014 as a “meeting of minds” between Dobson and his business partner Pini Reznik. At the time, Dobson said, he was a chief technology officer focused mainly on application development, while Reznik had been busy building ops and infrastructure for TomTom.
“Container Solutions was an experiment,” Dobson recalled. “I’d always been interested in feedback loops and developer experience, and (Pini) had worked with containers at TomTom. Mostly we were curious to see what might happen when we put our heads together.”
The two had no formal business model or idea, just an interest in distributed systems and a willingness to surf along with the ever-accelerating cloud computing sector. These instincts paid off: Container Solutions found itself at the forefront of the DevOps/containerization movement, leading a revolution so new that few could offer true guidance or expertise. The unfunded startup managed to get to a headcount of 40 staff with projected earnings of $10 million in 2018 — a mere three years after launching.
A World with No Name
“These days we operate in a cloud-native world that didn’t even have a name when we started Container Solutions,” Reznik said. “For us, though, it was clear this would be the technology that would emerge.”
It was something of a risky bet; in 2014, not many companies were using cloud-native technology at all, much less with any skill. There was no Kubernetes, and Docker itself had launched only the year before. Reznik and Dobson doubled down on their vision, working hard to stay on top of the rapidly evolving sector while insisting on only taking projects to be built with the new technology.
“You’re not always as visionary as you’d like to think, looking back,” said Dobson with a laugh. “But mainly we just kept an open mind our first year.”
“It was difficult. At first, we spent a lot of time working with vendors just building tools around this ecosystem and doing marketing to show its potential,” Reznik said. He described building MiniMesos in 2015. “We were building microservices frameworks and it was impossible to do testing on the framework. This was before MiniKube — so early in the evolution, we had to create it in order to be able to use it.”
“Even two years ago, hardly anyone would do anything more than simple experimentation projects in this area,” he concluded. “Now, it is common practice that containers and microservices are the optimal way to deliver software. Now, Cloud Native has a name, and the large corporations and tech vendors are all behind it.”
“Still in an Experimental State”
Not that Cloud Native architecture has been completely solved — not by a long shot, said both men. For example: if you need anything around VMs, the full solution exists. You can hire staff who understand that solution, your internal devs know how to use it. This is not yet the case with Cloud Native solutions.
“There are lots of tools, but we are still in an experimental state. Even Kubernetes and Docker are still experimental and can’t solve all problems,” Reznik said. “Then you have devs who don’t understand how to use containers and build distributed systems“As for microservices — very few devs even know where to begin.”
Many companies find this out the hard way when trying to make the migration, he continued. “They start with microservices and move into containers and then they get stuck. Or else first they say ‘let’s put our stuff in containers’ and then realize it makes sense to move to microservices. Either way, it gets very messy, and in most cases then they come to somebody with experience.”
One Is the Loneliest Number
“It’s very clear that what the market now needs is implementation,” said Dobson. “The only problem being, there are simply not enough people able to do it.”
After a year in business, Dobson said, Container Solutions settled into its identity: “We started to realize what we are is a vendor-neutral professional services company. Meaning our advice is trusted because we don’t sell anything,” he explained. “The only vendor-neutral (cloud-native) professional services company in the world — we can’t seem to find another one.”
“It is important that we are vendor-neutral,” agreed Reznik. “Though we officially partner with Google, Amazon and Microsoft, we are not committed to selling any specific solution. We will choose the best tools for each client and each situation.”
Container Solutions uses a structured approach involving three stages: discovery, or defining the vision; identifying and road mapping the process to the solution; and, finally, implementation.
“We take an integrative and iterative approach, with simple small steps, and learning built in continuously along the way. Meanwhile, we are also building our exit strategy,” said Reznik. ”We help the (customer) to a better situation and ultimately leave it in their hands to operate: that is our exit strategy. The only way we can exit is if they acquire the skills and knowledge to run everything and deal with problems independently.”
An approach radically different from the typical consulting model, built around selling a solution and then sticking around long-term to troubleshoot and operate it — of course, billing all the while. Reznik calls that model “value limited” in any sector, but especially in cloud-native consulting. “You can’t just come, install OpenShift, and leave. Most companies don’t know how to operate containers and microsystems. And we are not interested in remaining on site doing it for them…”
“Instead, we try to convince our clients that the sooner we deliver, the sooner we can exit. It’s better for everyone.” — Pini Reznik
Loyal Retainers
Container Solutions’ unique value proposition to “solve problems and move on” also redounds internally, enabling the company to attract and retain top talent in a very small and competitive hiring pool.
“Our engineers are curious and excited about working with new technology — if you leave them on a project for a year they will get bored and leave,” said Reznik. ”They love solving problems and learning new things, so if we were tasking them with doing the same Jenkins situation over and over, we’d lose them. Fast.”
The promise of this kind of reliably varied and challenging work is like catnip for talented engineers and developers, which makes recruiting simple. In addition, however, Container Solutions is committed to an enlightened, whole-person employment approach. According to Dobson, “We believe in old-fashioned treat each other with dignity, which is radically in vogue again. I was allergic to the bro culture at 22, in the height of the dotcom boom, and I’m allergic at 42.
“The last couple of years companies have stumbled on these old ideas: mentorship, coaching programs, and psych program as part of the company culture. That last sounds radical but makes real sense if you believe one purpose of a company is to serve the people in it. In-house support can help a manager who needs to learn to give effective feedback or someone who has fear of public speaking, or someone with autism or anxiety who struggles with change. We just want to help people crack their own ceilings to high performance.
Our goal is to grow the next generation of empathetic engineers who will go on to solve the world’s next problems. We promise to get them the best training available and a safe environment in which to innovate and we are able to do that. We have very interesting work.
We’ve never been able to pay market value salaries, but our mission draws good people to us. And we hold on to them; only three people have chosen to leave over three years. It’s hard work, don’t get me wrong — customers shout at us sometimes.
The only question is, as we continue to grow, will this scale larger? It’s a big concern of ours.”
Open Source
Container Solutions not only strives to match client problems with appropriate solutions, they further strive to make sure those solutions are open source whenever possible.
“If possible we try to contribute directly to open source projects and avoid customization that the client would have to try to maintain on their own,” said Reznik. “Everything we do is open source first, unless the client for some reason needs otherwise.”
We have a large enterprise client who needs CI/CD. They use Kubernetes, have CI, some sort of CD, but it’s not great. They have the tools to solve the problem but they’re not doing it in the best way. It’s possible to patch it together with all kind of tools and make it work, we call Frankenstein CI/CD but there’s no single platform yet where you can just install it and it all works. We are in big need of new techniques to do Cloud Native CI/CD in right way.
So we had to try to figure out what that will look like when it finally comes to exist. Then, find tools to solve it for now — while still moving in the right direction for the future. It can be difficult to differentiate, actually, between the processes of vision creation and implementation because, if you are experimenting with new technology, you’re often doing both at the same time.
For this client situation, Reznik’s team eventually found the GitHub project Jenkins X — which even now is still in experimental mode — and realized they had been moving in the proper direction. Jenkins X fit the use case perfectly.
“We were delighted to find the existing solution, but if we can’t find that perfect thing then we build something open source,” said Reznik. “Our clients often need similar things so we can cooperate between them — behind the scenes, using same ideas and techniques from one to another. And then contributing upstream whenever possible so others can benefit as well.”
Clients to the Left of Us, Google to the Right…
This is an organization that somehow manages to find itself simultaneously on the leading edge of technology, and in the middle between clients and vendors. It’s territory that suits both Dobson and Reznik just fine.
“We are in the middle because, in many situations, we are the missing link,” said Reznik. “The clients need implementation and education; if there is a piece lacking, we can code and implement it on our own. Then we can go back to Google, to other vendors, and we can tell the stories so they can learn to make their side better. Collecting this type of market research and feedback is terribly difficult for vendors, actually, because the client companies rarely tell them.”
On the other hand, he added, most companies don’t realize that you can even ask Google questions, that you can, say, email Google’s vice president of Kubernetes. “(Google) knows us as a company, that we can talk to them on the same level,” said Reznik. “Maybe they answer our emails because we filter out noise — because we only come to them with questions we cannot solve ourselves.”
Back… to the Future
Dobson’s favorite aspect of cloud-native architecture is how it organically creates a positive and adaptive situation for developers.
“In computing, after 1985 to about 2015, work for most engineers meant deploying software, move it to the production server, and in maybe 48 hours they could see results,” he explained, comparing it to a painter moving a brush and then having to wait two days to see the stroke of paint. “Most programmers get into this because they are creators — if you can’t do what you want to do, are prevented from it by the very processes that define your work, it will make you neurotic.”
“Cloud services let you have instant insight into your code, your changes,” he said. “This lets us get back to being creators.
Disclosure: Container Solutions retained editorial approval of this story.
