The Slim.AI Blog

A New Workflow for Cloud Development

Leverage the benefits of containerization without the headaches & hassle

John Amaral

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

At Slim.AI (opens new window), 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 (opens new window) 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 (opens new window) 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 (opens new window) 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 (opens new window) and we’ll send you an invite to our private beta.

Related Articles

See All Articles