In my previous articles I covered the general view and the first “seamless” step you can take when moving to the cloud. As you progress with cloud adoption you will realize that’s only a stepping stone in your path. It reduces the amount of work you’ll need to do initially, but it shouldn’t be your end goal. Your end goal needs to be embracing what it’s called Platform-as-a-Service (PaaS) or what I would rather call designing for the cloud.
So what does it mean to embrace a Platform as a Service design? It means to start using solution providers for your application building. This means you won’t have an OS or a single monolithic application. Your main building blocks will be APIs & cloud services.
Let me describe this by example, and for that I propose to think of an E-commerce Website designed in this way:
– For the overall solution you will use a Web Application Framework. Common examples are Django, MERN, Symfony, etc… It is important to choose a framework which uses a widely adopted programming language, this will allow you more options when choosing runner services.
– For the persistence you would normally run your own database server, but for the cloud you should use a database as a service instead. No matter if you choose to use a relational database or a NoSQL DBs, you can simply use it as a service and shift the maintenance to your provider.
– What we used to call web hosting before, it now becomes a “runner”. This is called Serverless Computing. There are providers which focus on this kind of services specifically. In this category a major player is Heroku, but it is not alone.
– For the Authentication and Authorization you won’t be building your own solution, instead you’ll be using a service/API which will handle most of the hassle for you. There is a big player in this segment: Auth0.
– As mentioned in the last article Logging and Monitoring is a very important thing to include when you are designing for the cloud. There are lots of big players in this field, but I would like to mention New Relic in particular for this category.
– For image or file storage you can rely on object storage services. At least for me the most recognizable one in this category is S3 from AWS.
In this E-commerce example you can see we have categories, each of these categories have providers. Cloud big three players (AWS, Azure & GCP) have solutions for each of the above categories, but there are other providers. Just to give you an idea, please take a look at this table:
By now you can realize that the range of options is big, and to keep this “simple” I only provided one alternative to the big three cloud options. I just want to keep the article as succinct as possible, there are much more.
Sadly not everything plays well together, and once you start building with a provider, you are including dependencies into your solution. But luckily for us, most of the web frameworks have abstractions you can use to keep your solution as agnostic as possible. An example of those abstractions for object storage means using libraries like object-store python or SMCloudStore. To be honest I haven’t used either of these example libraries, but I hope you get the idea. In any case, service providers do share code samples for their solutions. So you can build your own abstraction using their basic code. It is just important to keep in mind you might want/need to switch services depending on costs.
The most important thing to learn for building your own cloud solution, is what the above categories can provide. I know it might be a bit daunting at first, but you just need to learn how to use these services. Scaling is super simple when using cloud centered solutions, maintenance is most of the time built in, and in most cases you only pay for what you use (there might be some basic costs).
I guess the main takeaway of this article is to understand you need to learn to design software solutions differently for the cloud. And you need to get exposed to these new moving pieces. To me the easiest way to learn was to focus on one provider first (in my case was AWS). Once you get the hang of it, the next step would be to make sure you can use other providers as well.