A New Workflow for Cloud Development

Our goal is to make it easier for developers and DevOps to leverage the benefits of containerization without the headaches and hassle inherent in modern build cycles.

We’ve heard how developers struggle with the current Docker toolset and why container best practices don’t work. What can we do differently?

At Slim.AI, we’re engineering a new workflow that puts developers in charge of how they build and optimize their containers, leading to fewer issues down stream, faster development loops, and better security.

Our goal is to reduce the friction between application developers and DevOps teams by providing tools that automate the process of building and shipping containerized applications. We want the cloud-native development process to keep shifting left.

We know that DevOps teams want small, secure, lightweight images that are easy to handle in the CI/CD pipeline and run smoothly in production. And we know that developers want full-featured images that have the tools and libraries they need to speed development. But how do we get there?

Let’s take a look at how the developer workflow has changed since the advent of Docker and modern DevOps workflows.

In the pre-Docker era, we would play an endless game of ping-pong between Development and Operations. Teams would request resources, script deployment, and enter the “commit-and-patch” cycle as they triaged dependency issues or requested Ops support. We called this “dependency hell”.

h/t coolabnix.com for original diagram

These iterative loops were not only annoying, they were time consuming and open to security breaches. Most detrimental, in the view of DevOps philosophy, they made frequent, continuous deployments nearly impossible.

Docker promised to counter these iterative dependency loops. Dependency issues could now be sorted out in local build-test cycles and ops teams could focus on providing configuration details necessary to deploy through the CI/CD pipeline.

h/t coolabnix.com for original diagram

What this workflow doesn’t show, however, are the critical pain points that developers face even in this streamlined process:

• Building a safe and optimized container is difficult, labor intensive, and requires “tribal knowledge”
• “Dependency hell” hasn’t been removed, simply moved to the application development process, reducing some of the chuck-it-over-the-wall dynamic.
• Developers often don’t know what’s required for an image to work, so they leave unnecessary files, libraries, and dev tools in their containers, causing bloat and slow startup times.
• Generic downstream systems don’t have a reliable way of optimizing images. This becomes particularly nefarious in the increasingly popular serverless deployment environment in a managed Kubernetes cluster, where your container may take longer starting than it does actually running.

Let’s look at how it works today, using one of our favorite cloud platforms, Amazon ECR, as an example:

1. Dev writes code, packages into Docker, and commits
2. System ships code through pipeline
3. Automated processes compress images and run automated tests
4. Container gets pushed to cloud environment (be it dev, staging, or prod)

It’s not a bad state of the world if you make two massive assumptions: 1) the developer is able to find the right Docker container and build it correctly, securely, and in a timely fashion; and 2) the system knows what’s necessary and what’s not for optimization and security at each state of the SDLC.

In our experience, neither of these are true.

The workflow we are proposing at Slim.AI takes the manual effort out of both the Build and Deploy steps above.

Our guiding principles to achieve this vision are simple:

• We need to change our mindset on container optimization: It is not just about size, performance, and security. Containers also need to be developer-friendly.
• Developers need tools that automate container optimization across all stages of the SDLC, reducing manual efforts to move from dev to production.
• Our tools must also simplify common tasks like debugging, security, compliance, and continuous improvement, allowing devs to focus on creating great apps.

We think this new workflow will change the game when it comes to how we build apps. It will give developers more control, make systems safer, and increase throughput in the system.

Interested? Stay tuned for the the fourth and final article in our series for a description of the tools we’re building right now. If they sound like something you’d like to test out, get in touch and we’ll send you an invite to our private beta.

Slim.AI is a developer-first company. We like to keep things simple and transparent, and want you to be a part of that. We’re always looking to connect with people passionate about developing apps the way we do: Cloud first, ready for scale, and as efficiently as possible. If you’re interested in working with us -whether as a tester, design partner, or as a colleague or code contributor- join our community at Slim.AI, reach out to us at community@slim.ai and get the app here. We look forward to developing apps with you real soon!