Distributed Cloud: Continuous Delivery Without Borders

5 min read

For me, continuous delivery is the ability for an enterprise development team to deliver changes to their applications as often as needed.

Things aren’t necessarily changing every second, but it's the ability that, if needed, you have the automation and the processes in place to do just that. To achieve true continuous delivery without borders, you have to understand what makes it work, what stands in the way and what you can use to do it better.

"Distributed cloud made real: Build faster, securely, anywhere”: Join industry leaders and a special guest for this virtual event. Register now.

Integration, deployment and management for continuous delivery

If I think of the pipeline as a tool that accomplishes continuous integration and continuous deployment, I think of a full enterprise process as having several pipelines:

  • Pull request feedback: When developers have a change ready, they’ll push it to a main branch. But they might want a pipeline that runs as they're making changes to look for coding problems, security vulnerabilities or cloud service misconfiguration. This shift left approach can be applied to anything in the developer’s workspace before they push their code to the main branch.
  • Continuous integration: This is taking source code from developers and turning it into a distributable asset — often a container image. After the change gets to the main branch, the continuous integration pipeline comes in, performing whatever build steps are required for the language, validating the code with unit tests, scanning for vulnerabilities and code quality and, ultimately, producing a container image in a registry. These are good areas for automation.
  • Continuous deployment: This is the piece of automation that picks up one or more of these container images and, in combination, deploys them to an environment —  for example, ‘dev.’ There, regression tests run against the whole application. The deployment pipeline can then take those images and push them into other environments such as ‘staging’ and ‘prod’; again, relaying through the pipeline is an area for automation.
  • Business processes and change management: Enterprise application development hasn’t changed much prior to the cloud native development model; we still see a lot of staging and pre-production environments. If you're going to be in a continuous delivery posture, you have to automate change management and business processes that allow changes to progress through the sequence of environments on their way to production.

So how do you automate decision-making? For decisions based on metrics, you collect the metrics and establish gates. You automate evidence collection in case something ever goes wrong and to demonstrate process compliance.

All of this is necessary to achieve continuous delivery. But automation doesn’t have to stop there. Production, monitoring, measuring, feedback loops — all of it can be automated as a means to connect the phases of development and provide a higher quality user experience.

Roadblocks to continuous delivery

For continuous delivery, you want standard pipelines that run on portable and open tools managed from the cloud platform. However, a hybrid cloud or multicloud environment can present some roadblocks: connectivity and portability.

  • Network connectivity: Ultimately, you need connectivity to get applications deployed to the location where they will run — whether in cloud or on-premises — right? So, if you’re in a protected environment on a virtual private network, you may have trouble maintaining security without a lot of complex configuration.
  • Portability: If the technology used to automate the pipeline is tied up with a particular vendor or a closed set of rules, that’s a challenge. While the tools may be generally available, if you have a particular machine, particular network or homegrown infrastructure, you may not have the right access for pipeline automation.

Where does distributed cloud fit into continuous delivery?

We know it’s not as simple as “build an app and deploy it,” so let’s look at it in parts:

  • Automate complexities: You need a central point of control where processes are defined and automated. To automate all the governance processes around an app is complex, and not something you want to do more than once. Sharing toolchain templates across the enterprise will unlock productivity gains.
  • Secure reliability: A central point of control doesn’t mean a single point of failure. The central point of control needs to be reliable. These processes need to be running on an architecture that takes full advantage of cloud scalability, multiple availability zones and automated disaster recovery so that the pipeline can run continuously.
  • Keep it simple: Now, you don’t want to pick a different technology to implement the same processes in each different environment. You want to keep it simple, so you select an implementation technology (and a way of running it) that is scalable and reliable. Most of the process is the same across environments, and, at most, you’re tweaking small details of how you push a change in a particular environment.

To achieve all of these facets of continuous delivery, you need a pipeline engine capable of doing work in all of those remote endpoints, even beyond the cloud. Remote pipeline execution is important, and that is where distributed cloud comes in.

Distributed cloud and IBM Cloud Satellite

Distributed cloud is for those trying to enable continuous delivery across boundaries, beyond borders, both on-premises, in a public cloud environment and in edge delivery sites. It’s a way to get the cutting-edge technologies from public cloud providers and keep the flexibility and freedom to run your workloads where you choose.

 

Our distributed cloud solution, IBM Cloud® Satellite, is architected to support a single pipeline with multiple, remote points of delivery. Clients’ applications deploy over in-place management networks instead of the public internet. Our pipeline is providing that continuous delivery into the environments where customer-facing applications need to run.

But that’s not all. Beyond an architecture for a one-to-many cloud native application development and delivery pipeline, IBM Cloud Satellite provides public cloud services wherever you want to run them. For example, to efficiently generate insights from data through machine learning, you can provision IBM Cloud AI and data services wherever where your data resides.

There’s a lot of choice when it comes to continuous delivery services. Ultimately, for me, IBM Cloud is different because we provide guidance on how to have a continuous delivery process that includes all the security, compliance and audit readiness you care about.

Anyone can say, “Go automate,” but to be able to know what you need to automate, and how best to do it in order to be successful in your industry — for that, you need a true partner, which the experts in the IBM Garage offer. As a distributed cloud as a service, IBM Cloud Satellite provides consistency with cloud services used across environments. As experts in taking advantage of that consistency, the IBM Garage enables teams to efficiently learn as they produce minimum viable products that meet real business needs.

Be the first to hear about news, product updates, and innovation from IBM Cloud