Cloud Platforms and the Application Development Paradigm Shift
With the selection of a Cloud Platform becoming a standard part of a startup’s journey, you’d expect startups to make in-depth exploration of the platform’s possibilities a part of the process, or at least one of the next steps.
As a CTO who’s had the chance to look into the kitchen of quite a few startups over the last few years, I have however noticed that this is rarely the case.
The landscape of early startups is a varied one. The non-tech ones that outsource literally every bit of tech (you’d be surprised how many of these actually exist) obviously have no idea, but even many tech-co-founded startups are actually struggling to see/leverage the extra value a Cloud Platform can bring. They act on instinct, having a gut feeling that in the end, it’s better to hop on public Cloud than to keep operating on local data centres, or get attracted to public Cloud because of one of the many sponsoring programmes out there that convince them to make the move.
In fact, much to my own surprise, Cloud Platform selection turns out to not always be driven by a technical strategy, but by commercial dealmaking. Getting all Cloud services for free for a year or more, is of course very appealing.
Time to shed some light!
First, it’s important to note that the fact that you host in the Cloud says little about your application architecture, nor about performance and scalability.
In fact, I’ve seen many startups that have experienced that their app’s performance went down by moving to Cloud!
Of course, there’s an obvious explanation for this (see under ‘Mind your Chattiness’), but first things first.
Whether you start in the Cloud or migrate to it, you’re landing at a certain Cloud level. Cloud Platforms differentiate between Infrastructure as a Service (IaaS) and Platform as a Service (PaaS). The picture below shows the aspects of your application you will have to manage versus what your Cloud Provider will manage for you:
To be honest, the above image presents a simplification. It lets you first dip a toe into the whole story, because the full truth will be harder to swallow (isn’t it always?).
We need to add two more Cloud Levels: Container technology or CaaS sits between IaaS and PaaS, and the most recent addition, and increasingly popular, is Serverless (aka FaaS):
Apart from learning a few acronyms, these graphics convey a simple message: moving to the higher levels of the Cloud, you’ll have less to manage, tweak, fix and support. All that infrastructural and low-level stuff can be taken care of by the Cloud Provider. Better still: they’re actually better at that than your own teams will ever become.
But that’s not my point. My point is about leaving traditional App Development behind and really understand how to make optimal use of the Cloud to remove scalability boundaries, to embrace Continuous Integration instead of doing periodic big updates, to start decomposing applications into small self-contained modules, to make Async a default mechanism, and more.
You will only start unleashing real Cloud Power when you start embracing PaaS & Serverless and Cloud Architecture Patterns.
Many developers still start out with local development, and when the time comes to deploy, quickly try to match a Cloud deployment model. Obviously, that mindset will not lead to great advancements when it comes to implementing Cloud Architecture patterns.
Of course, many development environments make it a breeze to deploy your apps to the Cloud nowadays, but again, Cloud Architecture patterns not included ;-).
I still haven’t met that many people who really understand how Cloud Application Development is such a different beast. I can identify at least two reasons for that:
- Coding education hasn’t been embracing Cloud Development much.
- What ‘Cloud’ is changes rapidly. Keeping up with it all is highly time-intensive.
The Paradigm Shift
Looking at Application Development over the last say ten years, there are few aspects that haven’t undergone a complete transformation in terms of best practices, with Cloud growing up.
This table shows a few of them:
This article isn’t about the individual Cloud Architecture Patterns that have replaced the existing ones. There are plenty of places where you can get hands-on explanations and how-to’s, and there are complete and very much up-to-date reference docs. What I want to convey is simple: open your eyes and look. The Cloud has changed stuff fundamentally.
Let’s dive a bit deeper to a few architectural aspects that have undergone a Paradigm Shift since the advent of Cloud in general, and PaaS and Serverless in particular.
Data Architecture
Why start with Data? Because data is your gold. And because real Cloud scalability can only be achieved if you have a good plan around where your data sits, how it flows and how you’re going to make sense (think profit) of it.
Where we all used to map a domain problem into a relational database scheme, we should now start with deciding which type of Cloud Data Store to use: NoSQL/Document stores, Table/Row stores, Binary/Blob Stores, Queues, etc.
In fact, a first step should be to differentiate between the different types of data your solution/platform manages and to do the selection of storage for each.
We call this Polyglot Storage.
Arguably, some of this isn’t purely related to the Cloud era. I would however say it has gotten a lot more relevant because:
- There are so many more options available and easy to access as Cloud Services
- Because Cloud Solutions by definition are more multi-tenant than traditional ones, juggling with the sheer potential volumes of data simply forces you into thinking differently.
Each type of storage has advantages and disadvantages in a given use-case. Streaming IoT data probably fits better in unstructured Document/JSON or Binary stores, optimized for optimized for big data and fast writes.
Highly structured and related account data might still fit best in an RDBMS, because SQL is nowhere near out-of-date.
Simple semi-structured data will probably sit well in table/row storage. And the great thing is, all these storage options are available as Managed Services in every Public Cloud, sometimes even in a range of flavours.
If you collect large volumes of data for each of the tenants in your SaaS system, you better think upfront about what will happen when you become successful.
Also, if you know that lots of your data will be there for historical purposes, why not move it to cheaper, easier to scale storage? Both AWS and Azure provide lower cost archive storage options.
Losing the Monolith
When I work with startups and scaleups, one of the first things I do is look at the chosen architecture and infrastructure.
On a side note: I will not use the term ‘microservices’ here because 1) it’s tied in too much with Container technology and 2) the term doesn’t acknowledge PaaS & FaaS (Serverless) simply because it was invented before that.
However, decomposing your large solutions into smaller, relatively independent modules is definitely beneficial in many regards.
The way to go at it might differ depending on your initial architecture and infrastructure, but in my experience, a very good approach is using the Strangler Pattern. The basic premise of this pattern is to iteratively isolate and replace modules in your monolith, keeping risk at the lowest possible level.
The most important reason to consider a strangler application over a cut-over rewrite is reduced risk. A strangler can give value steadily and the frequent releases allow you to monitor its progress more carefully. Many people still don’t consider a strangler since they think it will cost more — I’m not convinced about that. Since you can use shorter release cycles with a strangler you can avoid a lot of the unnecessary features that cut over rewrites often generate. — Martin Fowler
Of course, the Strangler Pattern isn’t the holy grail. Moving away from a monolith isn’t easy and each path will come with hurdles. But sometimes a phased, derisked, iterative approach makes a lot of sense.
The Async way
I remember the time when multithreading became a thing. Suddenly, you could have code run in parallel and make sure your Web Server didn’t lock up when multiple requests ran simultaneously. Those were the times.
If you’re still bothering to do multithreading in your own code (and deploy to the Cloud), it’s about time to consider other options. PaaS and especially Serverless (FaaS) Cloud offer ways you couldn’t even begin to imagine how to make work, as simple to use, out-of-the-box services.
Something that clearly got amplified by the Mobile Revolution is the fact that the UI shouldn’t block unless no other solution exists. In Cloud, a pattern of choice would be web-queue-worker. Responsiveness of your UI, and the fact that you’ll be notified later when a (background) process is done, is so established that most users will immediately feel frustrated when your app is not on point.
Having groups of tasks automatically split into small independent units is getting ever simpler in modern Cloud, if you just follow the guidelines and best practices.
Design for Failure — What?
Traditional approaches often equate reliability with preventing failure, but cloud-based systems are inherently different, so the design approach has to be different too. In the cloud, you’re dealing with greater complexity, more interdependencies, and unknown demand — millions of people could end up using your app! All of these factors lead to more pressure, (in the system), and complexity — thus more opportunity for failure. — David Bills
In a nutshell, in a complex Cloud landscape, failure is inevitable, so you better be prepared and design your solutions with built-in resilience so inevitable failures have a minimal effect on availability and functionality.
Easy Solution Deployment isn’t Easy
The traditional approach to application rollout was to deploy big and in slow cycles. Applications being big monoliths with a huge amount of inner, hard dependencies, I remember the stress my teams used to have to get the “big bang” to work flawlessly.
Since then, the average software solution has grown spectacularly in size and complexity, data size has exploded and underlying infrastructure setup is sometimes beyond comprehension of regular developers.
Naturally, the big bang approach needed to be phased out along the way.
The current trend is called Continuous Deployment, -Integration & -Delivery. Having such a deployment pipeline guarantees availability and quality, and if implemented well, certainly helps reduce the stress in your teams.
The reality is, though, that the whole ‘continuous’ thing can’t simply be implemented as a replacement for ‘big bang’, without first re-architecting your monoliths into smaller units with well-defined interfaces between them.
Mind your Chattiness
As noted above, many people experience a speed decrease when moving their apps to the Cloud. In many cases, this has to do with the chattiness of layers within the apps, such as between business logic and data layers. Chattiness being measured in amounts of cross-layer calls per request.
The latency between infrastructural elements in the Cloud, even within the same Cloud Datacenter, is mostly a tiny bit higher than in a situation where you run your app with a database server on the same machine, VM or local network. Even if we’re talking about a 1ms latency, that is a 1ms latency per call. I have seen situations where lots of refactoring was needed because requests went in the 20–30 seconds because of poor data access code that did lots of small SQL calls to aggregate some result and pass it to the user. You could say that the local environment is more forgiving and that the penalty of such bad design is felt harder in the Cloud.
After refactoring, the request was even faster than the original, on premises version.
Conclusion
Cloud development is fundamentally different from traditional software development. With the wide (and growing) range of mature and extremely scalable PaaS and Serverless services, current Public Clouds present a potential that is in no way comparable to traditional data centers. Leveraging that ‘Upper Cloud’ potential demands being open to learning new architectural principles and patterns. But if you’re willing to do some fundamental reorientation, it certainly pays off. A few benefits of moving to PaaS and Serverless are:
- Better cost effectiveness
- More agility & faster Innovation
- More focus on your Business Proposition
- Maximized Uptime
- Easier Scaling & better elasticity
