Cloud native: this ain’t your father’s cloud
The adage “the cloud is just someone else’s computer” is true: that someone else is just insanely good at actually running that computer. With the advent of high-value services, run in a way that’s beyond what any company can manage on its down, this image is rapidly changing.
In the end, everything runs on a computer that has storage and networking. On top of this, however, we see several types of high-value services being built.
We start out with those services that your IT department already considers as separate: storage, databases, load balancing, API gateways, the like. These are the things that show up in your network or infrastructure diagram. Then we have application-level services, such as machine learning, queueing services, identity management, or stream processing. These things usually show up in software architecture diagrams, and are typically embedded in some software stack you may have adopted. Using these services, the cloud providers have built offerings for business horizontals: mobile application support, internet of things, gaming backends. These serve as blueprints for well-thought-out solutions, working as building blocks that benefit from scale and experience. In traditional development, these would be represented by architecture patterns for typical solutions, or make-or-buy decisions for horizontal-specific components. Perpendicular to these, we have maturity services for monitoring and maintaining your applications.
Do what you do best… and gain a few skills
Each of these services is, in its own right, something that requires significant investment and skill to operate at the price point and quality that they’re offered. Also, they take some element of application construction, neatly define its boundaries (way neater than your own in-house architecture team would ever have the chance to), and build and run a service better, cheaper, and more reliable than you ever could–that is, if you’re willing to play by the rules. First rule is on functionality: you may have to re-architect your application to work with one of these offerings, and there may be key parts of functionality that are simply missing. Also, by picking these high value services, you are likely no longer “cloud agnostic”: the architecture of your solution will be highly influenced by the available services. Thirdly, consider separation of concerns: the cloud provider provides incredibly powerful building blocks, and it’s your job to compose them into something that’s valuable for your customer–if you’re just reselling the cloud provider’s service, there’s no use for you to be in the value chain. It’s now up to you to determine whether the opportunity cost of cloud lock-in outweighs the additional value provided by going all in with one provider.
White paper Cloud migration
Cloud migration: 5 effective steps towards a successful result. Download our free white paper. Do you want to migrate your organisation’s systems to the cloud? A cloud migration provides speed and efficiency, among many other advantages. This white paper is...
Cloud native ain’t your father’s cloud
This new cloud status quo is no longer a good match for the existing IT skills that come from traditional deployment. As IT departments, we need to start thinking in heterogeneous vertical building blocks in stead of horizontal, well-known services, and get used to more complicated price models. On the development side, we’ll need to suppress the urge to start building software right away, and update our architecture process find a good balance between high value, off-the-shelf services and custom development. Finally, as consultancies, we must develop a stronger sense of how to compose solutions using these tools, and take a more central role in the solution design process, not only in the development or operations of solutions. Cloud native ain’t your father’s cloud. Act accordingly.
