Inching closer to a container-less world.
When discussing the hosting of cloud native applications, most of the focus, naturally, is on the deployment and management of the workloads themselves at runtime. One aspect that is often overlooked, however, is the input into the hosting process, meaning converting your source code into something that can be deployed and run. IBM Cloud Code Engine can do this for you.
What is IBM Cloud Code Engine?
IBM Cloud Code Engine (announced on March 31, 2021) is a fully managed, cloud-based runtime that allows you to deploy cloud native workloads in seconds, without having to manage any of the infrastructure necessary to host it. This means no more installing and managing Kubernetes. No more learning about pods, replicaSets, deployments, auto-scalers, load-balancers and even YAML.
In my previous blogs (on deploying apps and batch jobs to Code Engine), and in the accompanying videos, you were able to see how easy it is to deploy workloads to Code Engine — in many cases, with just your container image name and a few clicks of your mouse. However, starting with the container image still requires the developer to convert their source code into an image. For some people, this may not be very challenging, while for others, it might require a bit of a learning curve. Either way, perhaps it is something that should be done for the developer so they can spend more time coding.
Let us build the container image for you
For many developers, their source code will reside in a Git repository. With Code Engine, when you start the process of deploying an application or a batch job, you can choose to give it the location of that repository so that Code Engine can then build the container image for you. The obvious questions then follow:
- How does Code Engine know how to build the image?
- How does it know how to compile my code? Does it even need to be compiled, rather than just bundled with a runtime because it’s an interpreted language (e.g., Python)?
That’s where a “hint” is needed. If your code is fairly straight-forward, you might be able to leverage something called a “buildpack.” Think of a buildpack as a mechanism that will analyze your code, determine what language it is written in and then, based on that, will take whatever steps are necessary to make it “runnable” in Code Engine by creating a container image. For a compiled language, such as Java, it will compile the code and combine it with a JRE. For an interpreted language, the process might be as easy as copying the source code, along with the language runtime, into the resulting image.
If, however, you need a little more customization to build your image, you can do so by including a Dockerfile with your source code. A Dockerfile is basically a list of instructions for how to construct a container image that will run your code. It does this by allowing you specify what files should appear in the image — typically via some “compile” or “install” steps. Then, the process executes those steps and saves a snapshot of the container as an image.
You can control which process you’d like Code Engine to use via a simple flag. Since it’s not uncommon for people to share container images, you can also specify where the image should be stored — either for sharing or for later use during a deployment. It’s really that simple.
Where does all of this lead?
Let’s take a moment to think about the implications of what all of this means. Yes, it’s nice that people can go from “source code” to “running code” without having to build the container images themselves, but there’s something else here that might not be obvious. When you combine this with what we learned in the previous blogs (like deploying an app with just a few clicks), this means that a developer can deploy their source code to the cloud and never really need to think about container images, containers or even Kubernetes.
We are now getting really close to the point where the developer doesn’t even need provide anything more to the hosting runtime than their source code and desired runtime semantics. The requirement to even learn about “containers” at all might soon be a thing of the past. Maybe it’s wishful thinking, given the current state of things, but it does make the possibility seem a lot closer than it has in the past. And, this aligns with one of Code Engine’s design goals — meet the developer where they live, rather than make the developer adapt to the platform.
While Code Engine is still exploring if we can simplify this “image-building process” even more, you can see how it works today in a new video in which Erica Cameron demonstrates how you can quickly deploy your Code Engine workloads (either apps or batch jobs) directly from your source code:
After that, I encourage you to go try this out in Code Engine yourself. We offer a free tier so that you can play with it before you commit to purchasing. Check out the samples and tutorials that can help you jump-start your migration.
Ready to get started?
To start using IBM Cloud Code Engine, go to our landing page and watch more of our “Hello World” demo videos. Then, head on over to “Getting Started with Code Engine” in the documentation and deploy your first container, batch job or simply deploy your source code directly.
Was this article helpful?
YesNo