Blog

Many companies are moving at least some of their infrastructure and services to a serverless, cloud computing paradigm nowadays. Whether or not that's the right move for your company is a complicated question, but it might help to understand exactly what it means to "move to the cloud.”

Serverless vs Monolithic Architecture

A monolithic architecture is when all of your software runs and serves out of a single monolithic source — it can be one big process or several smaller processes all tied together. Traditionally, you would own servers to host these processes and be acutely aware of what server is running what.  

Serverless architecture, on the other hand, is a bit of a misnomer. There are still servers involved, but there isn't this one-to-one relationship of one service in one server.  Instead, there are frameworks like Docker and Kubernetes that allow you to run workloads and have resources assigned from a pool of hardware. When your service is running “in the cloud,” it's eventually running on one or many actual physical servers, but this process is not as personal as it was with monolithic architecture.

Public cloud providers —like AWS or GCP— own thousands of servers in hundreds of locations around the world. When you hire them to run your services, they're using serverless architecture to distribute your workloads and that of all their clients amongst their many servers. Additionally, there are also private clouds where you can run serverless architecture out of your own data center, but that's beyond the scope of this post. 

One huge benefit of public cloud computing is that you're paying for what you use, not what you own. You don't have to pay for the maintenance of the servers you're not using. You don't have to pay their power bill, or repairs, or upgrades; the provider takes care of that. This means hiring a cloud provider can be cheaper than running on your own servers. It also means that as your company grows and you need more capacity, you can immediately hire more space in the cloud instead of having to buy and set up new servers. It's even possible to set up an autoscaler that grants extra capacity for a period of time of high traffic, and then scales back down. 

Finally, should one of these machines break down, your service would quickly be able to spin back up on a different machine. If you hire more than one availability zone, one entire data center would go down and access still wouldn't be interrupted. And you never have to pay to replace, fix, or upgrade hardware.

Sounds great, so how do we go there?

There are many ways to migrate to the cloud. You have the option of just mimicking your current monolithic server functionality with the cloud — what is known as the "lift and shift” approach. But if you do that, you're really robbing yourself of having the full benefits of a serverless or cloud native architecture. You might still have more scalability, but you're have less efficiency and definitely more cost. A better approach is one that makes use of cloud-native services (services which were specifically designed to run on a cloud environment). Here's an example of what that looks like using the Plone CMS:

Plone on Metal vs Plone on the Cloud

Here's what a traditional Plone infrastructure in a monolithic environment might look like. This is how we used to serve our website sixfeetup.com, before we switched to serverless architecture. In this architecture, NGINX is the entry point for the user — it receives request and returns responses. Varnish is handling the caching. When a user requests a page that's cached and not stale, NGINX will serve it from Varnish.

If the appropriate response is not cached, then the request will go through HAProxy, which manages load balancing for the application. It requests the Plone instances which in turn get their data from the ZEO Storage Server. All of your data lives happily in your ZODB Database. This is all very simple and good, but there are a lot of pain points. You build in as many redundancies as you can, but there will still be servers that need to be taken down for maintenance. Additionally, you might get a huge load of traffic, or even a denial-of-service attack, and your service will be interrupted.

Let's compare and contrast the serverless architecture. This is how we serve sixfeetup.com now, making use of AWS Native Services. Here, you have CloudFront serving your front-end AND handling caching. It's distributed all over the world, so users see faster service, and it's more resilient since it won't fail in a localized outage of just one region.

Load balancing is handled by the Elastic Load Balancer (ELB), another AWS service. The next bundle of services are distributed in two availability zones. You usually want to pick a couple of availability zones in case one entire geographical region should suffer an outage. These are the actual locations where your containerized services are running. In these availability zones, you have the Plone App Server running on an EC2 Instance. 

The storage aspect is complicated enough to warrant its own article, but the main components are AWS Relational Database Storage (RDS), AWS Elastic File System (EFS), and finally AWS S3 Object storage for long-term backups. Together, these components act as a specialized back-end to the ZODB. A tool called RelStorage allows Plone to work with alternate relational database systems. 

Since there are 7 boxes instead of 5, this may seem more complicated — but some pieces were merged and others split for redundancy. In this diagram, every single service except Plone itself is an AWS native service. Plone is running on EC2, which is also an AWS native service. This means when your app scales, it can scale dynamically — only the pieces that need to be replicated will be replicated as needed. Sometimes you'll just need CloudFront to do more work, and at other times you may need to spin up a few more EC2 instances running Plone. On the cloud you pay only for what you use when you use it, so it can often be cheaper.

What is the best way to migrate to the cloud?

That question depends entirely on what your use case looks like. If you're migrating a Plone site, feel free to crib my architecture, but be mindful that there might be a different way to run things that's better suited to your specific needs. The best thing to do is familiarize yourself with all of the cloud native services and figure out how they might replicate the functionality you're used to. The big cloud providers — AWS, GCP, and Azure — all offer very similar services under their own brand names. It will benefit you to spend some time reading their documentation.

It is generally not advisable to “lift and shift.” If the service you run is so complicated, or for some reason you can't figure out how to have it run with cloud native services, you might consider just leaving it in the monolith for now. Finally, you might also consider hiring a cloud consultant to audit your architecture and offer solutions.