Life was good – your SaaS app was humming along, customers were happy, and business was booming. Then one day, it happened – a customer’s data is corrupt and needs to be restored ASAP! Or maybe a runaway job locked the database and brought the app to its knees, or a diligent customer demanded a more secure, isolated data store. You realize all your proverbial data eggs are in one basket, but you don’t want to maintain tens or hundreds of databases. Multi-tenancy is the solution to your problem!
Serverless applications are becoming more and more popular, but developers quickly find themselves asking, “How do I manage all of these functions?” Serverless Framework is a (relatively) painless way to develop and deploy your serverless application to AWS, Azure, Google Cloud, and other providers. However, getting started isn’t always easy. Here is an overview of how to get started with Serverless Framework using AWS and some common mistakes to avoid.
As a technology leader in your organization, many of your decisions come down to allocating resources: balancing and prioritizing risk and reward, stability and velocity, the present and the future. In an ideal world, technical debt would always be addressed before it started accruing interest. Long-term maintenance and operations expenses would be accurately weighed against the short-term development expenses that could mitigate them.
Migrating your database from an on-premise server to an AWS Relational Database Service (RDS) instance can be a daunting task. Moving a production database with continually changing data requires plenty of effort - especially if you’re also switching database engines.
Charity Majors, co-author of Database Reliability Engineering, shared a tweet that drives home how to approach the transition from single applications to a complex, distributed system of microservices.
@mipsytipsy. “Embrace the fact that everything is failing all the time - and it’s okay! We build for resiliency, not uptime.” Charity Majors, Twitter, https://twitter.com/mipsytipsy/status/1134499865335963648.
You can invest a lot in making any single system component reliable, performant, and scalable. The investment is often worthwhile and necessary, but what matters to users is the system’s uptime as a whole. Reliable components aren’t enough to make the entire system reliable if it’s unable to tolerate and recover from failures. Here are some thoughts about building your system for resiliency and two popular microservices patterns to cope with failure.