Cloud migration, containerized applications, microservices, and serverless operations can be a bit intimidating. There are a number of benefits to going serverless, but there can also be large costs when not instituted properly. So, VictorOps Director of Platform Engineering, Beau Christensen, sat down to chat with Tom McLaughlin, Founder of ServerlessOps, about all things cloud.
To open up the conversation and create a dialogue, Beau spoke to Tom about VictorOps’s own experience when deciding to move to AWS. Initially, VictorOps was adamant about maintaining its own data centers and staying off-cloud due to the inherent importance of reliability for an incident management platform. Beau stated, “VictorOps has tried to build services that were very simple based on basically bare metal hypervisors.”
But it was understood that this type of infrastructure was hard to maintain at a smaller scale. So, VictorOps looked at both Google and Amazon when deciding where they wanted to migrate. Initially, the team was very excited about going with Google. But, after a deep dive, Beau found the differences between Spinnaker and Aurora multi-master made Amazon a better choice for our needs. The speed and capability to deploy more decoupled, simple services made AWS the right choice.
With very small teams, you can deploy to a single region, at least three data centers, with multiple availability zones (AZs) when running on the cloud. Once you’ve experienced that first deployment, you then have the knowledge and tools necessary to go to multiple regions and/or multiple vendors.
Instead of managing multiple data centers, regions, or vendors yourself, you can leverage the speed and capabilities of Amazon Aurora Multi-Master to help you. You can create multiple master instances and if one of them fails, the other instances in the cluster will take over immediately. With these failover measures, as long as you have enough capacity, even through complete AZ failures, you can create an environment with zero application downtime.
Redirecting your resources to the cloud and creating multi-region or multi-vendor instances offers more flexibility and speed than managing your own data centers. Multi-instance infrastructure can create failover measures that maintain uptime and make end users happier.
VictorOps initially went through a lift-and-shift strategy as a way of learning when we first moved to AWS. Now that the application is up and running, instead of redeploying staging and lift-and-shift style, we’re simply deploying a cloud-native version. This way, you can shift traffic to that while already having a backup ready to go. With the lift-and-shift method, once the application is in the cloud, you can restructure and remove parts of the code and connect them over as SNS, SQS queues, etc.
Discussing the migration led Beau and Tom into a conversation about microservices. This then led to Tom discussing why he’s working to popularize nanoservices, a microcosm of microservices. The purpose of nanoservices is looking for reusable patterns and repurposing these services for multiple needs. Tom discussed an example of a service he uses to publish to Slack.
“It’s input interfaced, it’s an SNS message with a message value that’s Slack chat postmessage JSON doc. That’s it. And now, any time I want to start feeding data into Slack, all I have to do is write something that takes data in, formats data, and publishes it to SNS. And, I can keep reusing this one little service.”
Beau and Tom also discussed some of the benefits and costs of serverless architectures vs. on-premise architectures. The conversation started out heavily discussing the additional financial burden that serverless might have. Because price is based on the amount of instance load, the harder you work your system, the more it will cost.
But, Tom went on to discuss that the benefits outweigh the costs. You also need to remember that, generally speaking, you aren’t being charged for idle time. Tom spoke out strongly that people need to start thinking about serverless as a revenue generation tool, not just a cost. Think of the benefits it brings to your customers. The speed at which you can create and deploy new features is much higher, constantly bringing value to your customers.
One last major topic from the conversation came toward the end. Beau and Tom discussed the difficulty in creating observability around serverless infrastructures. Due to the fact you don’t have control over the whole process, it’s harder to get visibility into everything. Especially when you begin running containerized applications or microservices in the cloud. With services a little more isolated, tracking down exactly where failures occur can be difficult.
Both Tom and Beau agreed that it’s important to implement actionable ways of monitoring exactly what’s happening with your microservices. Tom mentioned that giving context for individual functions can be started by asking a few questions, “Here’s its input source, here’s its output source. And then, what is putting data in? And where is that data going?” Work out systems to know exactly where failures occur and work up or down the chain to really understand how your system is working.
Cloud migration and hosting are never the same. Whether you’ve maintained a microservice application in the cloud for years or you’re just now migrating, incidents will occur. Every organization runs into roadblocks and questions when building out their cloud-based infrastructure. Always keep in mind how you can make customers happy while building a reliable service.
VictorOps is purpose-built to help teams rapidly develop and maintain their services. Download our free Incident Management Buyers Guide to see how incident management software helps you build at the speed of DevOps.
Tom McLaughlin is the founder of ServerlessOps, a DevOps transformation and AWS cloud adoption advisory company with a specialty focus on serverless. He’s a cloud infrastructure engineer by background and writes regularly on serverless operations.