Patterns resonate with me. As a developer and software architect stepping back and viewing a population of things to find the common thread woven throughout seems natural.
Exploiting that thread in other areas if it’s valuable or adding it to my “Refactor someday” list if it’s harmful has always seemed to be a logical next step. Recently, I’ve started to see a pattern in conversations with some of my customers and internally with several of my talented colleagues.
Cloud Native Application Platforms
The conversations have been broadly along the lines of how an organization should go about adopting new platforms to help address organizational objectives. Objectives varied but often consisted of increasing development velocity (speed to market), simplifying operations (cost reduction), modernizing applications (legacy retirement) and more.
Specifically the conversations have been focused on adopting cloud native application platforms (this encompasses a rapidly developing set of technologies including platform-as-a-service and container-as-a-service). As technologists, the adoption discussion inevitably jumps quickly to the platform selection process.
Setting up the requirements for quantitative analysis, teasing out the qualitative fit of a given set of tools, and establishing the right set of selection criteria. Though the quantitative and qualitative aspects are critical, and the evaluation should follow a well-established process to avoid re-inventing the analysis wheel, there is more to adoption than selection of tools and platform.
We must train our thinking to avoid the pattern of strictly evaluating adoption steps based on technical characteristics of the platforms. We need to broaden our approach to consider several other aspects.
First, are our teams ready to adopt modern application frameworks? Do they have the right skills and coaching to make that transition?
Secondly, if there was any sense that the current development and deployment processes could remain without modification that thought process requires some serious analysis of its own. We should expect significant change in how our development and operations team will interact with the new platform as well as the roles they will fill. And lastly, this is a bit different than the others but it is an unfortunate pattern, the build-your-own approach to application platforms should never part of our selection process.
Let’s discuss these a bit further.
1) Not evaluating modern application frameworks
In some cases projects may want to bring forward existing applications to the new platform with as little refactoring as possible. This expedites migration and modernizations efforts but rarely leaves the application in a position to full leverage the platform capabilities and often fails to provide the expected value.
The platform typically bears the blame but this should fall squarely on the shoulders of those architecting the application. To truly gain value from the platform rethinking the application framework and architecture must occur.
Adopting the 12-factor application concepts, exploring emerging languages (Ruby, Python, Go, Scala, etc.), evaluating other frameworks to provide services (caching, notifications, proxies, service mesh) to the application, and reviewing cloud native application patterns (service discovery, circuit breaker, distributed configuration) are all critical aspects of leveraging cloud native platforms.
2) Forgetting development culture
Focus must be given to improving your existing build and deployment pipelines. Not just the tools you leverage but the areas of waste within your existing processes.
How can you take this opportunity to optimize your development process from idea to production? What steps will no longer be necessary, are low value, or can easily be automated to accelerate your delivery? And is your organization ready to adjust to these changes to facilitate platform adoption.
Looking at how to apply principals from Continuous Delivery, Lean, and Agile should be part of your evaluation process and critical to adoption success. Don’t forget that the existing role will likely shift as well, don’t expect the some activities to persist across your current delivery process and to your cloud native application platform. Roles must change to adopt to a new model.
3) Attempting to build your own application platform
Many of the platforms I’ve been in discussion about including: Pivotal Cloud Foundry and RedHat OpenShift, which are often compared against Google’s Kubernetes Engine or recently AWS EKS all have an upstream open source projects which are the foundation for these vendor solutions. In some cases, well-meaning but inexperienced guides will suggest “saving money” and going with the upstream open source project to build their own application platform.
I can not stress enough how disastrous of an approach this is to take. With very rare exception, you will not find any competitive differentiator or costs savings long term being in platform building business.
In that case you’re competing against the Pivotal, Google, and Redhat’s of the world. You will end up frustrated trying to keep the platform current and realizing your are re-creating what already exists a majority of the time.
There’s much to be said on the topic of platform selection and adoption. For now I simply want to highlight that a measured approach to platform selection is important and at Perficient we do have a entire cloud native application platform selection process.
It includes customizable evaluation criteria, an analysis tool with pre-built templates, a set of readiness checklists, and more. But the analysis of your cultural environment is equally important.
Your developers and operators must come into focus early in the decision making process. The decision on how you will build and automate your deployment processes going forward are critical and shouldn’t be left as an afterthought in your analysis. Avoid these bad patterns and experience the success that comes along successful cloud native platform adoption.
