A closer look at the all-new IBM Cloud Code Engine and the benefits it offers.
We recently announced IBM Cloud Code Engine—our newest platform for hosting all of your cloud native workloads. Whether you’re interested in hosting web applications, serverless functions, or batch jobs, Code Engine is designed to support them all in a developer-centric user experience. Let’s explore what this really means.
The promise of cloud computing
First, let’s remind ourselves that one of the biggest selling points of the cloud computing revolution was a simplified experience. Whether it’s the self-service model or the idea of abstracting away the complexities of the underlying infrastructure, cloud computing was meant to make our lives easier and, in the end, increase our productivity. Has that promise come to fruition?
To answer that question, it might be worth exploring all of the decisions that people need to make while choosing how to host their workloads:
- Do you want the ease of use of a platform like Cloud Foundry?
- Do you want the flexibility and power of Kubernetes?
- Is the dynamic nature of serverless computing something of interest?
- What if your workload doesn’t fit into the traditional HTTP web-facing model, which one is the right fit then?
The decision for each of these comes with their own set of benefits and costs. Some are more feature rich, but come with added complexity, while a simpler user-experience often means a restricted set of features. Some will also impose additional constraints based on implementation choices that the platform owner made. And, in addition, since the industry has been encouraging us to break-up our monolith applications into microservices, it’s very possible that not all of those components should be hosted on the same platform. Therefore, how easy will it be to integrate things if they’re spread out across different types of hosting platforms?
Then, beyond those concerns, there’s also the challenge of management. Each type of platform chosen will probably require a very different CI/CD workflow to be defined. Which of these choices will require significant time and resources to manage the infrastructure? What architectural and design choices of our applications will need to be changed based on these choices?
In the end, I’m not sure we can claim that the “promise of cloud computing” has really been achieved yet. In many respects, people have simply become accustomed to having to make these choices and live with the costs associated with them. With IBM Cloud Code Engine, all of that will change.
IBM Cloud Code Engine: Returning to the promise
Imagine if you didn’t have to make all of those choices. What if, instead, you could simply give your workload to the hosting environment and—only if you really needed to—you could specify a few specialized runtime characteristics that the workload needed, and that’s it? What if, instead of spending time trying to figure out how to get the hosting environment to do what you wanted, you could ask for the semantics you’re looking for and the platform figured out how to do it for you? In a nutshell, that’s what Code Engine aims to do—shift developers back to being developers instead of infrastructure specialists.
Code Engine is IBM’s platform for hosting all of your cloud native workloads. It combines all of the features needed by PaaS, CaaS, Serverless, and Batch workloads into one platform. And, it does it all in a managed publicly hosted environment—which means that all of the infrastructure, and management of that infrastructure, is no longer something you need to worry about. Additionally, since Code Engine has a “pay as you go” model, you’ll only pay for the infrastructure resources you actually use.
Let’s explore what this all really means by discussing what Code Engine offers:
-
Built on open source: At its core, Code Engine leverages some of the most popular cloud native, open source technologies. That means Kubernetes, Knative, Istio, and Tekton, among others. This means that while Code Engine introduces its own simplified user experience, if you really need to go around that UX, you can. Your existing deployment scripts should still work on Code Engine, if you really like to deal with the complexity of the Kubernetes data model.
-
Simplified deployment model: Kubernetes has won the container wars—it’s that simple. However, with all of the features Kubernetes has to offer, that doesn’t mean users of the system should be forced to manage its complexity for all use cases. So, as mentioned in the previous section, Code Engine has developed a simplified user experience aimed at allowing the simple cases to be solved with minimal effort. It’s only when you choose to use the more advanced features that you’ll be exposed to the more sophisticated options. While most of the same features are still available, the difference with Code Engine is that it is more of a progressive disclosure model—one where you choose when to see certain features based on your specialized needs, and not simply because the platform offers it.
-
Auto-scaling and concurrency controls: With Code Engine, you have the ability to auto-scale your applications based on the load being targeted towards them. This means, as more traffic is sent to your app, Code Engine will automatically scale it up and then back down again once the flows decrease. Even all the way down to zero. However, this is your choice. You can, via a simple configuration knob, tell Code Engine how high or low to scale your app—and even how quickly to do so. You’re in control over how concurrent the system thinks your app is—meaning, can it only handle one request at a time, or can it handle hundreds? No complex components to install based on your workload—just set a flag and Code Engine will handle it for you.
-
Source-to-image: While for some of us, creating container images has now become a normal part of our workflow, to others it’s just an annoying low-level detail that they’d rather not deal with. With Code Engine, you can choose how you want to deploy your app. While you can choose to point Code Engine to an existing container image, you can also provide your source code directly (via a Git repo), and Code Engine will build and manage the container image for you. Those familiar with Cloud Foundry will be right at home here.
-
Batch workloads: Many workloads are HTTP-based or event-based, meaning they react to some incoming HTTP request message, but there are some that are not. For example, batch jobs are often not triggered via a normal HTTP request; instead, they are initiated by some manual process or by some time-based trigger. When they’re done with their processing, instead of waiting for another trigger, they simply shutdown. Often, these are called run-to-completion tasks. Code Engine supports these as well.
-
Integration with IBM Cloud Services: Code Engine is a hosted offering, so you’ll have access to all of the IBM hosted services from our cloud, such as IBM Watson and IBM Db2. The integration with those services is as seamless and easy as the rest of the Code Engine.
-
Built-in security: Obviously, security is important for any workload. That’s why you’ll automatically get SSL protection built-in without any extra configuration needed. Code Engine will manage the creation and deployment of your SSL certificates automatically.
Bringing it all together
While the individual features listed above are impressive, IBM Cloud Code Engine brings them all together in a simplified UX. For those who are accustomed to using Kubernetes, imagine how much time and learning there would be to enable all of the features listed above—it’s non-trivial. With Code Engine, however, you can have an auto-scaled and fully secure workload available on the internet in minutes.
Want to learn more?
IBM Cloud Code Engine is available today! Come play with it—as of now, it’s all free since we’re in beta. But, going forward, you can count on there being a free tier for those who have small workloads. Here are some links to help you get started:
Was this article helpful?
YesNo