As the cloud computing architecture advances, the ways in which we define success must mature as well. In 2021, I pointed out that improving cloud computing is a binary process rather than analog.
What I said then is still true: “There is a lot at stake. Suboptimal and expensive infrastructures (clouds) may actually work, but they could cause the company to lose millions per week when most people are not wiser. Thirty technologies are used where it was from It is possible that 12 technologies will work better, and not designing for change means that business resilience is damaged.”
Why are most cloud architectures poorly optimized? During the planning and design phases, most cloud engineers do what they learned in cloud engineering courses, apply what they’ve read in any number of how to access the cloud references, or they may adopt advice they learned from previous cloud architecture projects and mentors. All of this directs the architect to a series of generic reference models, processes, and technology combinations that must be modified to meet the organization’s unique business needs. This approach consistently results in unimproved structures that cost organizations more (or far more) money than they should. What’s going on?
To answer this question, let’s take a step back. What does improved cloud architecture actually mean? I outlined a cloud optimization process in October 2020 and included a high-level model to take advantage of. I have enhanced the Cloud Engineering course to include this concept, Which will be released here soon.
Next, we need to realize that in the past the main focus has been on making everything work together, with little regard for how we will You have succeeded or the complexity of the solution. The measure of success was “Does it work?” Not “How well does it work?”
During development, the team kept laser focused on their approaches to cloud architecture, migration, and new network development, both at the broad (meta-cloud architecture) and at the narrow (micro-cloud architectures). Now it’s not about how to design and deploy cloud migrations and new developments to cloud-native, or how to take advantage of containers, serverless, or other small or large cloud computing solutions. Rather, it is about how you define your goals for this solution.
IT management and organizations in general are getting wise to the fact that a solution that “works” or “looks innovative” doesn’t really tell you why operations are costing so much more than expected. Today we need to audit and evaluate the end state of a cloud solution to provide a clear measure of its success. The planning and development stages of a cloud deployment are great places to plan and build into the post-development audit and evaluation process to measure the overall return on investment of a project.
This end-to-end offering will create some turmoil in the world of those who build and deploy cloud and cloud-related solutions. Most of them believed that their designs and buildings were sophisticated and designed with the best possible solutions available at the time. They think their designs are as optimized as possible. In most cases, they are wrong.
Most of the cloud solutions implemented over the past 10 years have not been significantly improved. So much so that if companies honestly check what was published versus what should have been published, a very different picture of a truly optimized cloud solution would form. There may or may not be enough use of containers. Or the failure to force a cloud-native restructuring—or failure to consider those advantages. Or the new trend I’m seeing, which is making multiple clouds more complex than they need to be and failing to define shared services across the cloud like security and operations. In some cases, the solution uses too many common services, but these situations are not uncommon.
Speaking generally, cloud architects apply what they’ve learned from books, videos, articles, and even ways that critics and I have reported on how to leverage technology. Architects identify what a business needs, and then match those needs with optimal solutions. This is a good approach.
However, let’s say Vendor A has the best native apps available for your financial operations, Vendor B has the best native apps for your CRM needs, and Vendor C has the best native apps for your inventory requirements. Going multimedia for the best strains of these three requirements, as well as dozens of other options (security, storage, networking, etc.), may not be in the overall interest of your organization. Each of these options adds another layer of complexity and cost that can quickly outweigh the added benefits.
This does not mean that you run out of the technology you use to build your own cloud solutions. Just be aware that getting to the most improved architecture is still more an art than a science. Sometimes you need to invest in more technology, sometimes less. The important thing is to identify something as close to optimization as possible.
Today, cloud optimization means that we must audit and re-evaluate our existing cloud solutions and then consider increasing metrics moving forward. This won’t be easy, but consider the potential value back to the business. In some cases, cloud optimization may save the business.
When there are cloud solutions that work, many employees on the “it’s good enough” team tend to become one or all of the three wise monkeys: they don’t want to hear, see, or talk about any evil about the cloud solution they’ve helped deploy or are currently working on. . On the contrary, there always seems to be someone on the team “Wait, it costs what?” Who understands that a cloud solution will continue to drain enterprise resources more than they should. They will be the first to suggest or insist on checking.
In which team will you be?