Aptomi: Kubernetes Deployment by Service for Multiple Teams
In the world of continuous integration/continuous delivery (CI/CD), the spotlight is focusing more intensely on the CD side of the equation, especially as containers, Kubernetes, microservices and serverless technologies add more complexity.
Startup Aptomi concentrates on services for Kubernetes deployment and working with them across teams.
“Deploying an application is not so simple once you start working about how different components interact with each other, how they affect each other’s state, how you deploy them in concert with each other, how changes affect the different components and all that stuff,” said co-founder Roman Alekseenkov.
“There’s really no framework to make the services aware of each other and roll them out in a way that reduces abstraction and how to do a collaborative process without stepping on each other’s toes. There seems to be an entire layer missing that provides this service-level abstraction that allows you to deal with services rather than containers. So we decided to solve this.”
He and co-founder Michael Dvorkin have been focused on building an application-delivery platform that’s completely declarative — you specify how things need to be, then it automatically handles deployment and configuration of all the underlying details — Kubernetes, service meshes and things in between.
Declarative Delivery
Boris Renski, Mirantis co-founder and chief marketing officer, is an angel investor in the project.
“I personally and Mirantis at large see continuous delivery for the Kubernetes space as the land of opportunity,” he said of his backing for Aptomi. “At Mirantis we’ve been investing in that direction as well with our focus on Spinnaker. I believe that adoption of smart infrastructure like Kubernetes and serverless is poised to disrupt the CD space.”
It’s a growing space. A Markets and Markets report put the value of the continuous delivery market at $1.44 billion in 2017 and forecast it will reach $3.85 billion by 2023, with a compound annual growth rate (CAGR) of 18.5 percent. Meanwhile, Gartner estimated the market for application release orchestration grew by 37.5 percent in 2017 and with a global market value of $282.6 million.
Aptomi’s fix on CD for Kubernetes takes it a step further towards the paradigm of declarative delivery, Renski said.
“Before, infrastructure was dumb and you had to embed the ‘how’ of deploying apps entirely in your CD pipeline — API call to hypervisor, bash script to configure IP table, Puppet script to mount storage, etc.,” he explained.
With Kubernetes and serverless, the infrastructure has become increasingly smarter and more and more of the “how” part is becoming offloaded to standard approaches at the infrastructure level; hence CD is evolving from focus on “how” (VMs and IP addresses) to focus on “what” (application end state); from imperative to declarative.
Multiple Teams
Aptomi was launched in April 2017 by Renski, Alekseenkov, the former senior vice president of engineering at Mirantis, and Dvorkin, a distinguished engineer at Cisco and chief scientist for Noiro, that company’s open source policy declaration and enforcement project.
Written in Go, Aptomi is a thin layer that sits atop the microservices infrastructure such as Helm and Kubernetes to enable you to run services across multiple environments and multiple clusters with different settings. It also supports ksonnet and YAML files.
“If you want to roll out an application with a couple of components, like WordPress and a database, it’s actually pretty easy. But if you want to roll out [multiple components], it keeps getting harder the further you go,” explained Dvorkin. More so if different teams own different parts of the application.
“Most applications that enterprises deploy fall into that last category — multiple components owned by multiple teams — and dealing with that is a bloody mess.”
Then you have notions of things like service discovery, how services consume each other, functions, how services react, how you regulate that, how you do network control — that’s not a solved science, he said.
You have a lot of moving parts to control — Kubernetes, API management, security, how to regulate trust and identity and networking. Then you have multiple environments, multiple stages in the lifecycle and multiple teams. All those complexities multiply.
“What I’m dealing with is a lot of hard coding… configuration files, policies, specifications. All this is managed very loosely with very little that ties them together. Aptomi tries to tie all this together and make applications super easy to deploy by providing a very consistent service model that’s optimized for distributed environments and distributed teams that can work together in a synchronous way,” Dvorkin said.
Clear Ownership
Aptomi provides a clearly defined separation of concerns. A developer or team defines the service and its dependencies as well as the operational, governance and security rules under which it operates. It’s clear who owns the service. The service owner can specify its behavior in multiple clusters or environments — such as dev, stage, prod—and control the life cycle and updates. Aptomi uses performance, state and operational data to adaptively enforce these requirements. The service can then be made available to other users and teams under the specifications the service owner has laid out.
Aptomi allows you to observe and control the service in context: You always know what dependencies exist, why they exist, who are running the service and where. Aptomi can also answer “what-if” questions about the effect of changes rules and configurations. And you always have the history if something goes wrong, Dvorkin said in an interview.
It does not require centralized ownership, but rather can be used by multiple teams in a peer-to-peer fashion.
In a post about service exchange, Dvorkin explained that the idea is to define the service as a self-contained entity — not according to any specific instance.
Then all underlying microservice architecture components are configured and observed, and higher-level service-centric policies are translated into the format that lower levels can understand and enforce through standard components such as API gateways, service meshes and container orchestrators, he wrote.
“We’re on this continuous enforcement loop and we convert all this stuff into containers that get deployed on top of the Kubernetes clusters, and we automate all the moving parts underneath,” Dvorkin said. “You don’t have to think about the details. We take care of all the configuration for you and allow you to focus on your services rather than focusing on infrastructure details.”
It also integrates tightly within the CI/CD pipeline, and allows you to treat everything as code — your service definitions, dependencies, policies, how the services interact.
The general enforcement engine which takes the packaged code, the rules, and runs a continuous loop on them. It also takes some real-time data into account.
“We monitor the state of the clusters, of applications, we also get input from some other management systems, like APMs can push parameterized data into to us… and we make decisions on what to deploy, where to deploy and how those things will interact with each other. …Deployed, we rely on Kubernetes to run containers, but we also make calls to service meshes [etc.] … and we can configure all the details underneath,” he said.
‘Living Organisms’
Others in this space include Spinnaker, which is backed by Google; Duplo and Codefresh, which just raised a $8 million Series B round led by M12, Microsoft’s venture fund. Dvorkin calls Codefresh a “really nice tool,” one with a more traditional CI/CD model for defining workflows and running CD pipelines in multicloud environments. Spinnaker, which Mirantis now offers in a commercial package, recently added automated delivery with machine learning and custom pipeline logic for multiple cloud deployments. Aptomi sits between CD pipelines and Helm.
“We’re not trying to describe the whole application. We’re only trying to describe the service that an individual team or developer owns,”Dvorkin said.”Others end up [using] your service, and that’s how we end up knowing the application graph in its entirety. Often applications are not static, they keep evolving. [Services are] like living organisms, they keep changing and can be updated at any time. We’re doing it in a way to minimize impact on the rest of the application.
“We’re providing this more declarative, intent-based application delivery platform,” he said. “Rather than running discrete steps, we’re running this enforcement loop and constantly adapt to the operational environment and the actual state.”
