Cloud architecture is a high-level design that outlines the overall structure and components of a cloud-based system and how those components interrelate, considering scalability, availability, security, and performance. It defines how various cloud services and resources are integrated to meet specific business or technical requirements. Better put, cloud architecture provides a blueprint for deploying and organizing cloud resources. Simple enough.
Cloud engineering involves the practical implementation and execution of the cloud architecture. Cloud engineers are responsible for building, configuring, and managing the cloud infrastructure and services to ensure they align with the architectural design, including themes.
Cloud engineers are also the last word on whether something works. Most of us have been on projects where technology was selected that did not function. Engineers should be empowered to overrule some architectural decisions to get to a more optimized end state.
These days, as generative AI dominates the tech press, those who follow this blog and the podcast often say that engineering is no longer a needed discipline. After all, if AI can provide much of the necessary coding, it should be able to provide the detailed engineering required as well. Right? Not so fast.
We need a collaborative approach with both disciplines. One cannot function properly without the other. For example, I cannot design multicloud-based systems that define different usages for different cloud services on different clouds. There are engineering certifications on each cloud and each service, and this specialization is required to get the details right. I understand how to build a security architecture, but how it’s deployed on each cloud provider is a level of detail that cloud architects typically don’t have. And they should not. They work from the general; engineers build and deploy each system using state-of-the-art best practices and approaches. This is also why the ratio of architects to engineers is usually one to many: one architect for many engineers. I usually have at least 10 on my deployment teams, depending on what we’re doing.
Why the confusion?
I’m not sure this is well understood these days, and I’m seeing some significant mistakes occurring as we run headlong to generative AI-based cloud services.
Many assume that the engineering tasks are the easiest part of the journey to the cloud. After all, if the cloud architect is good, the configuration should work, and it’s just a matter of using sound AI tools to carry out deployment.
Even worse, some companies are working just with engineers and hiring specific skills. The company may pick a cloud brand and hire security, application, data, and AI engineers in that cloud platform. They assume that this specific cloud platform is the correct and optimized platform, which will usually cause trouble. Oh, the solutions may work, but it could cost 10 times more to operate. Not surprisingly, these companies have an underoptimized architecture since they’ve given zero consideration to architecture or the use of cloud architects.
AI won’t save you from needing a good architecture and a good set of engineering disciplines. You need both, and given the complexities of generative AI, this need will grow in importance. I’m often taken aback that this is still a confusing concept, but those who don’t understand how to put some rigor into these system configurations and deployment capabilities, cloud or not, are likely facing an end-state solution that removes, not adds, value to the business. That can be avoided.