Over the holiday period, I watched the classic movie: The Wizard of Oz. In the movie, a tornado rips through Kansas, and Dorothy (Judy Garland) and her dog, Toto, are whisked away in their house to the magical land of Oz. Here they journey on the yellow brick road to the distant Emerald City to seek the help of the Wizard of Oz in hopes of returning home. Along their journey, they face many perils and meet many friends. This journey along the yellow brick road is similar to the trail map presented by the Cloud Native Computing Foundation (CNCF).
The CNCF trail is an overview for enterprises starting their cloud native journey. It recommends the various steps and associated technologies for the step; the path represents a tested and trusted path. CNCF says that everything after step 3 is optional. However, to know where you are and where you need to go, one must measure to keep CALMS, so step 4 is mandatory.
This journey/trail is the same journey which we embarked (with no map) when creating the cloud services which are part of the AMPLIFY platform over 2 years ago.
Step 1. Containerization
Two years ago within our portfolio, we had services which were born as 12 factor services and thus could be easily deployed in a container. However, we also had a lot of legacy services and products which were designed to be deployed in our customers’ environments (i.e. installed on-premises). We started on a mission of improving these legacy products, so that they would play well within the container(s) in our cloud. In order to begin our journey, we needed to understand our current state and how we could move to our desired state. To help us transform towards our desired state, we came up with a container maturity model and asked our teams to make progress upwards to Level 5.
| Maturity Level | Name | Description |
|---|---|---|
| 1 | Demo | The product is shoehorned into a container with little or no changes to the application. |
| 2 | Basic Resilience | The product can persist data and service can easily be restored. |
| 3 | Production Load | The product can scale to multiple nodes under load. |
| 4 | Production Remedy | The product meets the company’s internal security controls for release and can be upgraded/downgraded by simply changing the version of the image. |
| 5 | Low Impact Operations | The product can be upgraded/downgraded with zero downtime and scaled automatically. |
Getting to a container is a little like Dorothy’s ruby slippers – clicking them you can move anywhere just like the portability containerization provides you.
Containerization – the ruby slippers of cloud native. “There’s no place like home.”
Image sources: The Wizard of Oz
Step 2. CI/CD
As previously discussed, when your boss tells you, “We choose to go to the Cloud”, you will need to make significant levels of investment in your infrastructure for CI/CD. Just like the Tin Man needed a heart, a company needs deployment tooling. Being able to deploy to production quickly becomes the heartbeat of your company. In AMPLIFY, we have invested heavily in our CI/CD so that we can push to production as often as possible. Below you can see some screenshots of the monitoring of our CI/CD which we have put in place. Today, we’re at a daily cadence but during 2019 we’ll be moving to on-demand and performing multiple deployments per day.
Monitoring of our CI/CD just like a monitor on Tin Man’s heart
Step 3. Orchestration & Application Definition
The next step on the trail is “Orchestration & Application Definition”. When we started out, we adopted Docker Swarm for Orchestration and Docker Compose for Application Definition, but as time moved on, we could see that Kubernetes was winning the orchestration war. Luckily, since containers are the core deployment artifact, we were able to quickly make the switch to Kubernetes for Orchestration and Helm for Application Definition. Step 3 is just like Scarecrow’s brain; it will allow you to do many clever things like rolling updates to satisfy your CD or scaling in/out your application to meet your consumption needs.
Orchestration and application definition – the brains of your solution
Step 4. Observability & Analysis
Although flagged as optional in the CNCF trail map, I would say that this step is mandatory. As previously discussed, you must measure all aspects of your pipeline and production environment. When teams are continuously deploying (CD) this becomes the heartbeat of the business, which means we must make sure that we have a heart monitor in place so we know the system is alive. The trail calls out 3 distinct areas to look at:
- Monitoring represents the instrumentation of your application stack and monitoring the results. There are various levels of metrics that can be gathered to give you KPIs for the operations of the service and also to determine if the application addresses the business needs of the organization. In AMPLIFY, we have used many different tools from the CNCF landscape including Prometheus, NewRelic, and Grafana.
- Logging is important for debugging and checking up on the general health of your application. When things go wrong, we need logs to establish the reason as to why they went wrong. Given the expense of moving or storing log events, there is an important trade-off to be made between the utility of errors and the cost of moving/restraining the data. In AMPLIFY, we have used ElasticSearch and Splunk.
- Tracing allows for the debugging and observing of distributed transactions as they flow across multiple services in the solution. We looked at Jagger and Zipkin in AMPLIFY, but have not yet put these into production.
In Dorothy’s adventure, she is constantly being monitored and harassed by the Wicked Witch of the West. The witch uses a magic crystal ball, so that she can monitor and watch Dorothy as she moves along the Yellow Brick Road.
Wicked Witch of the West – monitoring everything and tracking the ruby slippers (containers)
The remaining steps on the journey are optional, but we’ve traveled through a few of them, such as the service mesh (step 5) where we built a solution for API traffic management for North-South and East-West traffic and gRPC (step 8) where we built a mechanism for messaging between ground (on-premises) and our SaaS services.
Finally, as you may have seen in the CNCF trail there are many dragons dotted along the way. So, the phrase “Here be dragons” means dangerous or unexplored territories exist. This phrase comes from the medieval practice of putting illustrations of dragons on maps where potential dangers were thought to exist. For our journey, just replace dragons with flying monkeys!
CNCF Dragons replace my flying monkeys – Dangerous or unexplored territories on the way to cloud native
The main challenge to be faced on the cloud-native trail is not a technical one. As clearly highlighted in the trail map, the path is well worn. The challenge is to achieve a cultural shift from traditional software development towards cloud-native development. An organization’s culture will trump any process, architecture, or organization changes. For this, the organization needs to have the Courage of the Cowardly Lion, so that it can successfully transform to be cloud-native and this is something that happens beyond the trail map. Culture is like quality. You don’t build culture, or quality, by talking about it. You build it by doing things, by acting, by making things happen and making things change, and reinforcing these actions patiently and continually over time, all the time evolving it and improving to meet our needs.
Cultural change required to move to the cloud requires the Courage of the Cowardly Lion
When you follow the yellow brick road, you’ll end up as Cloud Native. And, to quote Dorothy, “we’re not in Kansas anymore”. You will see changes to your processes (CI/CD), architecture and organizational structure. Organizations that successfully take on the journey will enjoy and benefit from increased agility and speed to market,
If you want to join us on our journey along the yellow brick road – we’re hiring. Find more details here: https://www.axway.com/en/company/careers