When I started opsZero in April 2016, it was a completely different DevOps arena. Kubernetes was beginning to mature, AWS Lambda was still in its infancy, and DevOps was getting started with its involved with Infrastructure as Code using Terraform. I wanted to move DevOps to a world where there were “No Idle Servers” and lo and behold so did other people, including the Cloud Providers.
We are now in a world where the abstraction has moved from the machine to the container. The technology to remove idle servers is primarily the norm and tools, and services like AWS Lambda and Kubernetes are the new abstractions. This new abstraction dramatically diminishes the need for dedicated DevOps and increases the power of the Developer.
The migration to Containers is in full throttle with Kubernetes having won the battle for Container Orchestration and is starting to stabilize. Serverless is beginning to mature at a consistent pace with AWS pushing hard with their Serverless stack. We at opsZero have needed to acknowledge that DevOps is going to become more self-serve for Developers. This self-serve nature is a good thing!
Since the game has changed since opsZero started, we need to change course. opsZero will be playing a new game which creates a significant change to our business model. However, we believe this model will increasing delivery speed, ensure higher quality, reduced variability, provide greater focus, and help us scale. This transition is essential because the model we entered the field with is no longer relevant in 2019.
These are the changes that will happen:
We will be discontinuing DevOps as a Service. When we started opsZero in 2016 DevOps as a Service made sense, but as we enter 2019, DevOps has subdivided into SecurityOps, DataOps, and more. However, we are not interested in the complications and one-off natures of some of those tasks as it is not our primary expertise.
The difficulty of scaling DevOps as a Service has become more and more apparent. The lack of repeatability has made it difficult to hire, and it makes it challenging to project deliverables. For example, our communication was becoming client environments x number of clients x members in our team. Each permutation and slight variability of each environment has resulted in knowledge transfer becoming almost impossible without basically the other team member redoing tasks.
This variability has lead to increased stress, and deliverables have become less consistent over time. Using the Theory of Constraints, our work has become variable with limited slack, which means that opsZero has become a bottleneck to our customers. Our quality of work has suffered, and most critically, each additional client has exponentially made our work suffer.
Because of the variability and breadth of work, we were willing to do growth has become entirely stagnant. Growth becomes harder to justify when the quality suffers so much. The lesson we finally learned is that we were trying to be too many things for too many people. What we were doing was not a business, but moonlighting multiple jobs.
A business needs hyperfocus on a few things such that it is a big fish in a small pond. In the book Competitive Strategy, Michael Porter states that a firm can have three different strategies Cost, Focus, and Differentiation. Everyone else is “Stuck in the Middle,” where their competitive strategy is not well defined, and they end up not doing anything well.
To get away from being “Stuck in the Middle,” we had to first decide what it is that we wanted to play.
All of these reasons are primary reasons to discontinue DevOps as a Service altogether. The lessons we learned have been hugely beneficial, and in retrospect, it was a mistake to wait this long. The cons of discontinuing DevOps as a Service will be that it will hit our revenue in the immediate term. However, our transition will allow us to focus on the core DevOps values that make us happy and hopefully make our customers happy.
Our new game entails hyperfocus on three specific verticals and creating tooling around those three things to best help address the market. However, before we get to those, I want to get into some personal history about why I got into DevOps.
I started programming at a young age around 12. I remember coming home from school in 8th grade to install Linux 2.4.0 after waiting to download it on a 28k dial-up modem for three days. I installed it on my Slackware Linux machine only to have it completely hose my computer… Well, I kept at it and got better and fell in love with systems, Linux, UNIX, and the open-source community.
However, when I first started working, I was a backend engineer. I worked on software systems, and I loved that, but deployment in teams always sucked. I entered doing DevOps because I wanted to make the lives of backend engineers easier. I tried to make deployment easier so that products could be created faster. I wanted people to deploy code more quickly so that customers could start using them sooner. I wanted people to waste less time deploying code and less time in QA and more time moving rapidly forward.
My true passion is the speed of idea, to code, to customer. That is what opsZero’s Vision will be, “Ideas Deployed Faster.” Since the best way to get code deployed faster if you want to run within your Cloud is Kubernetes and AWS Lambda, those are where opsZero will focus.
Kubernetes is the dominant orchestration tool and the one that is the most generic across all the Cloud Providers. Furthermore, tools like Helm allow creating deployments of common services within the Kubernetes environment. By using Helm, Developers can deploy additional services as part of their code deploys.
Furthermore, Kubernetes fulfills an opportunity to cost savings, repeatability, and future-proofing for companies. As the Cloud vendors take on more and more of the role of addressing the Kubernetes market, there will be legacy apps that will need to be migrated. We will be focused on migrating these apps over to Kubernetes and will work on accelerating the migration to the Container world.
One of the considerations we have is that many companies have stringent compliance requirements that need addressing. So to increase the pool of Kubernetes users, we have released AuditKube, a set of Terraform scripts that allow us to create a consistent Compliance-oriented deployment. The scripts will allow us and others to develop consistent Kubernetes environments across AWS, GCP, and Azure using our partners Foxpass for authentication and LogDNA for Logging.
TL;DR 1. We will migrate legacy apps to run on Docker and Kubernetes 2. We will create a set of repeatable scripts for a compliance-oriented Kubernetes environment.
We find that most companies do not have a good CI Pipelines even in 2019, and we see that being a significant pain to address. However, the significant change in 2019 is that tools like Helm and the Serverless Framework also us to address infrastructure needs. Engineers can add Services to their CI/CD pipeline to test out new services like RabbitMQ, Redis, Elastic, etc. quickly.
As part of helping companies migrate to Kubernetes, we will set up a CI/CD Pipeline that will create repeatable deploys that include:
To ensure that we can do this quickly, we are working on a set of scripts called DeployTag, written by Kyle Barton, that will allow us to set up CI/CD Pipelines with less variability quickly. By reducing variability, we can have more consistency and hence, a better deployment pipeline. We want people to deploy 100 times a day if they desire and be able to create new environments to test out features rapidly.
TL;DR 1. We will create repeatable CI/CD Pipelines for Companies using Helm and Serverless Framework
The future of the Cloud is Serverless. We are still in the early adopter stage of this migration, but the most mature environment so far is AWS Lambda, but Google and Azure will also play in the field. However, we have to pick a horse, and for Serverless specifically, that horse is AWS Lambda.
Many applications benefit from AWS Lambda:
The majority of apps likely fall into this realm and are likely idle, costing money and using energy when they could just be running when invoked. Our environmentalist sensibilities want us to migrate services off these self-run idles computers and into the Cloud.
However, AWS Lambda does have pitfalls, and they will be addressed over time as Amazon invests money and energy. However, we think a majority of applications can migrate to AWS Lambda now and gain all the benefits that it provides.
We will develop our strengths around AWS Lambda and start developing good development practices that will allow us to migrate codebases over effectively. However, we will need to figure out how to effectively do this and reduce the variability that is common with most codebases.
By focusing on these three verticals, we are setting ourselves to address the market needs and future market growth. By limiting our efforts into fewer things, we can set our customers and ourselves for future success while ensuring high quality, speed, and most importantly reduced variability.
To do these three things well, we will be doubling our efforts into creating processes, setting up automation, building a partner network, and increasing our open source contributions.
We don’t think DevOps will go away, but a majority of tasks will become more specialized over time, and we must understand and exploit our strengths. We have always been interested in getting ideas to the world faster, and we are finally at a stage where we can do that with Kubernetes and Serverless. We are excited to start moving forward and hit work on our next iteration!