Microservices
If you’re not familiar with Lambda, it’s a AWS feature that’s meant to give you a way to quickly write a service and let Amazon worry about all the boilerplate junk that normally goes with standing your service up in a way that people can actually talk to it. You don’t configure subnets or instances or load balancers with Lambda: you just write some code and then tell Amazon to hook you up. It’s a pretty compelling promise.
When we at Ambassador Labs tried to actually use Lambda for a real-world HTTP-based microservices we found some uncool things that make Lambda not yet ready for the world we live in:
Lambda is a building block, not a tool
February 9, 2016 | 12 min read
Microservices
Microservices appear simple to build on the surface, but there’s more to creating them than just launching some code running in containers and making HTTP requests between them. Here are 10 important questions that you should answer about any new microservice before development begins on it – and certainly before it gets deployed into production.
1. How will it be tested?
Microservices have an interesting set of benefits and drawbacks when it comes to testing. On one hand, unit testing a small service that represents a well-defined piece of functionality is likely a lot easier than testing an entire monolithic application. On the other hand, verifying the quality of a whole application that is composed of many microservices can represent a significant amount of testing complexity: instead of running a single command to test the code running in one process, a large number of integrated dependent components must be running first, verified as healthy, and stay running throughout the tests.
February 2, 2016 | 15 min read
Microservices
Microservices are the latest hot trend in software architecture – and with good reason. They create a path to Continuous Deployment in cloud-native environments, giving organizations increased business velocity and flexibility. However, that speed can lead engineers to focus too much on the business features they are more easily churning out and forget that their new highly distributed system could in fact be more prone to failures than would a similarly-scoped monolith. This is because resilience is an oft-overlooked concern in microservices development.
A wish to make systems more resilient was at the heart of the “Fallacies of Distributed Computing”, originally penned by L Peter Deutsch in 1994 when he was at Sun Microsystems, and augmented by a few others since then. The fallacies read as follows:
The network is reliable.
January 19, 2016 | 11 min read
