The latest posts and insights about Ambassador Labs - our products, our ecosystem, as well as voices from across our community.
API DEVELOPMENT
January 30, 2025
API Development
The single most important thing to remember about software is that there is No Magic Every behavior you see, every effect you run across, only happens because some code is making it happen, and it is always possible to track that code down.
Telepresence
Let’s cut to the chase: you’re adopting a microservice architecture, and you’re planning to use Docker. There’s a reason it is so en vogue – it solves lots and lots of problems and has zero negative effect on our projects, right As with every tool, technology, or paradigm thrust upon us as we scrappily try to maintain our sanity while jumping from shiny to shiny, we need to learn the gotchas. To do this, I like to start with a simple question: How might this new shiny bite me on the ass, and what can I do to avoid having teeth marks on my rear? I want to tackle a problem I have seen repeatedly during my consultations with teams/organizations adopting Docker. Behemoth Docker Images
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?”
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.
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
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.
