The cloud is now ten years old, if you view Amazon Web Services (AWS) as kicking off the cloud industry with its inaugural EC2, S3, and SQS services back in 2006. It’s an industry, and IT offering, which has been through the proverbial hype-cycle to become a mainstream IT solution that’s now used and accepted by enterprises of all sizes, and in all industries, around the world.
However, the general public’s understanding of cloud doesn’t tally with the maturity of the cloud. A recent US survey revealed that half of Americans think that cloud computing is affected by the weather (and this was before Google data centers were hit by lightning). In Australia, a quarter of active cloud users didn’t know they were using the cloud. This is okay though as one of the benefits of cloud is hiding the complexity of the IT.
It’s not just the general public that struggles with cloud. New cloud providers and new cloud services have turned the cloud terminology dial up to eleven (did you like my Spinal Tap reference?) to make the cloud look like an even more complex place – even for hardened IT professionals like me (Editor: who are you kidding, Joe?). To help, or at least to confirm people’s understanding, this two-part blog demystifies some of the latest cloud terms:
Applications are a combination of programming languages, software architectures, supporting services, and let’s not forget the actual code and data. And there’s a best-practice approach to creating applications in the cloud, which is called “cloud native.” This best practice has reached a level of adoption and standing that it now has its own foundation called the Cloud Native Foundation (CNF).
It brings to mind an old saying:
“If it looks like a duck, swims like a duck, and quacks like a duck, then it’s probably is a duck.”
So just as a duck has its nature, this best-practice thinking states that a cloud native application’s nature:
The polar opposite of cloud native applications are 1980’s, monolithic mainframe applications or your 1990’s client-server applications. These could be migrated to the cloud as-is, but the chances of them working are unknown, whereas the missed opportunity of being able to exploit cloud features is known.
Microservices is the name given to a specific software architecture style that is well-explained, and in detail, by Martin Fowler and James Lewis. They describe microservices as an alternative to monolithic software architecture that is favored by cloud application developers because microservices work well with “the grain” of the cloud.
If monolithic software architecture applications can be imagined as one large, possibly enormous, program, then microservice-architecture software can be imagined as a swarm of single-purpose software components that work together. If this doesn’t help, and all you can now think of is bees, then Wikipedia describes microservices as:
“…a software architecture style in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs. These services are small, highly decoupled and focus on doing a small task, facilitating a modular approach to system-building.”
Microservices are particularly suited to cloud native applications, and to cloud in general, because of the following:
Microservices are increasingly being implemented not by virtual machines but instead by containers, which I’ll come back to in Part 2.
Well that’s it for Part 1, otherwise this blog would be 1800+ words long. In Part 2, I’ll return to cover: containers, hybrid and composite clouds, and software-defined everything.