Microservices
In my experience, most of the effort associated with adopting and owning microservices is due to lack of automation and the repayment of microservice technical debt. Teams moving from monolith to microservices might discover natural points of segregation in their existing code base. For those working in an object oriented language these points typically occur at an interface (in the object-oriented sense of the word, or protocol), or a point where an interface should be.
Microservice Technical Debt Problems
A problem with monolithic code bases is that even segregated components share the same memory. Specifically, they share access to the program itself. It is as easy to code to interface as it is to code to implementation. Further, it is as easy for a developer with access to an entire code base to refactor an interface as it is to refactor implementation. “But wait,” you might be thinking, “making things easy is a positive trait.” “Why is this a problem?”
April 18, 2016 | 9 min read
Microservices
Last week, our Chief Architect, Rafael Schloming, presented at the Node.js Meetup in Boston on The Other Kind of Distributed System.
The talk covers the intersection between distributed systems and distributed development. Developers are already used to thinking about the challenges of dividing a single large task into many smaller tasks – something we often call distributed computation or distributed systems. Today, though, the challenge of dividing development into many smaller pieces is arguably more critical, for example, divvying work amongst distributed teams.
February 29, 2016 | 2 min read
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
