Cloud architecture is shooting up again as a hot topic. Cloud architects are hard to seek out, salaries are rising, and lots of are seeking cloud architecture training.
Most architects are really just material experts on one public cloud provider and don’t understand other providers and the way they will work and play well together. This causes some cloud deployment failures as architects to become more and more myopic, using an equivalent technology stack regardless of if it’s a fit or not.
I’m finding that a return to traditional architectural processes used 20 years ago could also be a far better fit cloud computing in 2020. However, they have to be modernized for the way we build solutions today and therefore the technology we use.
“Paralysis through analysis” will always be a risk. Moreover, traditional sequential architectural processes (waterfall) fly within the face of the new world of agile methods, which are automated by very slick DevOps toolchains and processes.
Cloud architects must avoid these two extremes:
First is thinking that you simply can iterate your thanks to cloud architecture success in record time. the appliance development model (getting it wrong repeatedly before getting it right) is an accepted process for optimizing application development and reacting quickly to changing business needs. However, an equivalent approach won’t work for architecture, unless you propose on spending many dollars unnecessarily to urge to the proper, fully optimized architecture. you only can’t adopt expensive technology or cloud services that way without adding an incredible amount of risk and price.
Second, those that check out cloud architecture as a slow trod, burdened by committees, selection teams, etc., where it takes a year just to select the elemental cloud technologies, will find that the planet changes faster than they will continue. They’ll deploy an architecture that’s out of date the day it goes into production.
So, what’s the simplest path to a successful cloud computing architecture? the simplest practices lately are really around “fast planning,” and that’s something I practice a day. Really, it’s old fashioned meets new school.
First, create a master, enterprisewide logical architecture to supply a foundational understanding of what the cloud architecture is, in reference to the prevailing enterprise architecture. Don’t assign any part of the logical architecture to a selected technology. this is often the vision that you’ll build around—the macro architecture.
Second, decompose the logical (macro) architecture right down to many microarchitectures. In most Global 2000 companies this maybe by the department, technology platforms, data storage, security models, or all of the above. Break the macro architecture apart in order that the microarchitectures are solvable using fast planning.
Finally, leverage custom processes around each fast planning sprint for every microarchitecture. Simply put, this suggests time-boxing the design cycle for every microarchitecture to a couple of weeks or maybe a couple of days. These should be decoupled and may be wiped out sequence or in parallel.
It’s interesting how we’d like to mash up approaches from the past with what’s working now, all fueled by the necessity for speed. the simplest architects keep an open mind about technology, processes, and methods. we’d like to be continuously improving.