NoOps is the result of higher abstraction (and automation)

I touched on NoOps in my last post for two reasons. First, I wanted to note that DevOps and NoOps solve the same problem but in different environments. Second, I wanted to reference Anchorman and Star Wars in the same blog.

I finished by mentioning abstraction and part II. Well, here it is.

I’ll approach it from two perspectives. The first is resources such as databases and message queues. The second is applications and services.

Traditionally, infrastructure complexity demanded a dedicated ops team. Installation, configuration, monitoring, maintenance, troubleshooting… there’s a lot to it. However, the cloud abstracted most of it away. Note, I’m going to refer to AWS services below. For example, we no longer have to submit an ops request when we need a server. We can create EC2 instances ourselves.

Still, there’s more to infrastructure. What if we need a database?

The cloud offers higher levels of abstraction. If we need a database, we can create an RDS instance. We don’t need to provision a server first and then install the database software. Nor do we have to worry about maintaining it. That’s on AWS.

Then there is the application. Where do we deploy it?

Arguably, this is where containers come into play. I’d go with ECS, which runs on EC2 instances. Of course, we’ll need to create a container for our app first.

However, when it comes to RDS and ECS we need to understand resource utilization. What size EC2 and RDS instances do we need? Which EC2 instances should ECS run on? Capacity planning can be tricky, and if not done right, quite costly. Then there is scalability. When do you scale up, and how far? When do you scale out, and by how much?

This is where the next layer of abstraction comes into play, serverless. If we go with Aurora Serverless and Fargate, we don’t have to worry about any of these things. AWS will scale our database in and out as needed, the same for our application.

Still, in my mind, microservices offer yet another level of abstraction. As a Java developer, my app requires an app server like Tomcat or Wildfly. These app servers require administration when it comes to production environments, and AWS isn’t going to do that for us too. 

However, if I shift to microservices, I don’t have to think about an app server. I’d probably use Quarkus or Micronaut. Spring Boot is an option as well. Now, I’m simply deploying an executable, which is perfect for containers. Though I’d want to move to an even higher level of abstraction, functions. Then we could use Lambda fronted by API Gateway.

We no longer have to worry about servers, databases and app servers.

But, we do need to get our code from GitHub to the cloud. There’s services for that too. I happen to like CircleCI. Now, we can add continuous deployment to the list of things we no longer have to worry about.

However, all this abstraction and automation isn’t exactly free. We’re going to need serious expertise in these services if we want to be successful with them. In short, we’re going to need AWS experts. And, to be fair, these services require at least some management and monitoring. After all, while AWS is responsible for the services, we’re responsible for how we handle any outages or interruptions in them. We’ll need some expertise in containers too.

This brings me to the last abstraction, PaaS.

It’s not a new concept, but by taking advantage of serverless and microservices, PaaS offerings can make NoOps a reality by a) taking our code in GitHub and turning it into containerized apps running and scaling in the cloud and b) removing the need to understand the ins and outs of various cloud services.

Simply put, the perfect PaaS makes running apps in the cloud as easy as possible.

And that’s exactly what we’re doing here. I can’t wait for everyone to see the next iteration of the FL0 platform. And don’t worry, you won’t have to wait long.

Get great content updates from our team to your inbox.

Join 86,000 subscribers. GDPR and CCPA compliant.