“I love taking hours or days to deploy and operate my applications because I need more time to figure out how to scale clusters, create Kubernetes objects, YAML files, and stay on top of monitoring, security, cloud infrastructure APIs, and a myriad of Ansible and Terraform scripts and more"
By “No One Ever”
Platform and DevOps Engineering teams are finding themselves squeezed between two unrelenting forces. On one side, there are the business-driven demands to “Go faster! Open things up!" On the other side, there are business-driven demands to maximize security and stability. Your over-burdened team is in the middle, doing their best to avoid being squeezed beyond the breaking point.
Working with many organizations, it was clear to us that scaling a microservice-based architecture takes a lot more effort than expected. Some of the issues below are constantly found:
Organizations build teams to create and manage tens of clusters, and the clusters are likely separate for each team in their organization. Wrappings and tooling around them, control planes, and abstraction for these clusters need to be built, along with many other tasks. Throwing more people, tools, and processes at the problem is not the answer. This approach does not help achieve the goal of releasing applications faster.
Security is not trivial! Most teams haven’t been able to implement security and control layers across their multiple clusters effectively that guarantees security requirements are met. At the same time, Developers need to be able to focus solely on their code.
Teams that are working to adopt or scale Kubernetes face conflicts as the complexity increases dramatically. They try to maintain security levels, application services, monitoring, and other tasks, and the result is that Developer experience and performance is heavily impacted.
Day to day operation of large numbers of clusters requires a lot more effort on infrastructure management than defining controls and monitoring apps.
Achieving a large-scale production level with a microservices architecture involves maintaining and supporting many open source tools and integrations. Adding additional multi-tenancy complex requirements make things really complex!
Developers don’t want to, and shouldn’t have to, spend time learning and developing for Kubernetes. Doing so impacts the Developer experience and slows the delivery of applications. Fast delivery of applications adds value to the organization! These diversions can create opportunities for misconfigured objects, lack of understanding of how apps should be deployed, and other issues.
At Shipa, we define this problem as Lack of Application Context
Our goal at Shipa is to allow Platform, DevOps and Development teams to:
- Think Applications
- Not Containers
- Not Clusters
- Not Ships
Updated about 14 hours ago