Articles, tagged with Services, providing techniques, guidance, and best practices for how to build web applications that scale to significant traffic volumes.
Microservices is a hot topic in software development circles these days. And for some very good reasons. Put simply, the traditional way of building enterprise applications—using a monolithic approach—has become problematic as applications get larger and more complex. So developers are turning to a microservices software development architecture, in which applications are structured as collections of loosely coupled services. This makes them easier to build, and—more importantly—much easier to expand and scale. Let’s take a closer look at how a microservices approach differs from a monolithic one, and examine their relative strengths and weaknesses.
In the world of applications, services are standalone components that, when connected and working together, create an application that performs some business purpose. But services come in a wide variety of sizes, from tiny, super-specialized microservices up to services big and complete enough to form their own monolithic applications.
Technological innovation drives every business, industry and sector - mostly positively, but not always. 2016 was no exception – from the first long-haul driverless cargo delivery to automated retail locations to the stiffening competition among ‘smart assistants’ we’re seeing big technological leaps at a breakneck pace.
Take a look at the article Microservice Architectures: What They Are and Why You Should Use Them>, written by me and published by New Relic.
It’s an increasingly common scenario: As a company grows, it finds that it needs to move away from the monolithic software architecture that powered its initial success. The alternative? A microservices approach that provides more speed and flexibility. That’s the story told by both our guests on the latest episode of The New Stack @ Scale Podcast: Tung Nguyen, vice-president of engineering at Bleacher Report, and our own Lee Atchison, principal cloud architect & advocate at New Relic. Listen to it on New Relic’s Blog.
Traditionally, software companies created large, monolithic applications. The single monolith encompasses all business activities for a single application. As the company grew, so did the monolith. In this model, implementing an improved piece of business functionality requires developers to make changes within the single application, often with many other developers attempting to make changes to the same single application. Developers can easily step on each other’s toes and make conflicting changes that result in problems and outages. Development organizations get stuck in the muck, and applications slow down and become unreliable. The companies, as a result, end up losing customers and money. The muck is not inevitable, you can build and rearchitect your application to scale with your company, not against it.