Algorithms :: Digitalization :: Enterprise Service Bus :: Information Architecture :: Service Component Architecture :: Service-Oriented Architecture :: SOA Reference Models :: Web Services


Microservices: a definition of this new architectural term

Martin Fowler: The term "Microservice Architecture" has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.
- Microservices -

Introduction into Microservices

Oliver Wolf: This article explains the purposes and risks of microservice architectures. It further gives some hints on how an architecture must look like to met these purposes. At some points it also compares microservice to traditional service oriented architectures (SOA).
- Microservices -

A Microscope on Microservices

The Netflix Tech Blog: Coburn Watson, Scott Emmons, and Brendan Gregg: At Netflix we pioneer new cloud architectures and technologies to operate at massive scale - a scale which breaks most monitoring and analysis tools. The challenge is not just handling a massive instance count but to also provide quick, actionable insight for a large-scale, microservice-based architecture. Out of necessity we've developed our own tools for performance and reliability analysis, which we've also been open-sourcing (e.g., Atlas for cloud-wide monitoring). In this post we will discuss tools that the Cloud Performance and Reliability team have been developing, which are used together like a microscope switching between different magnifications as needed.
- Microservices -

Microservices at Netflix: Lessons for Architectural Design

In some recent blog posts, we have explained why we believe it ss crucial to adopt a four-tier application architecture in which applications are developed and deployed as sets of microservices. It is becoming increasingly clear that if you keep using development processes and application architectures that worked just fine ten years ago, you simply can not move fast enough to capture and hold the interest of mobile users who can choose from an ever-growing number of apps. Switching to a microservices architecture creates exciting opportunities in the marketplace for companies. For system architects and developers, it promises an unprecedented level of control and speed as they deliver innovative new web experiences to customers. But at such a breathless pace, it can feel like there is not a lot of room for error. In the real world, you can not stop developing and deploying your apps as you retool the processes for doing so. You know that your future success depends on transitioning to a microservices architecture, but how do you actually do it?
- Microservices -

Microservices, Monoliths, and NoOps

Arun Gupta on the difference between monolithic applications and microservices.
- Microservices -

Netflix's Viewing Data: How We Know Where You Are in House of Cards

The Netflix Tech Blog: Over the past 7 years, Netflix streaming has expanded from thousands of members watching occasionally to millions of members watching over two billion hours every month. Each time a member starts to watch a movie or TV episode, a view is created in our data systems and a collection of events describing that view is gathered. Given that viewing is what members spend most of their time doing on Netflix, having a robust and scalable architecture to manage and process this data is critical to the success of our business. In this post we%u2019ll describe what works and what breaks in an architecture that processes billions of viewing-related events per day.
- Microservices -

Microservice Design Patterns - Miles to go 2.0 ...

The main characteristics of a microservices-based application are defined in Microservices, Monoliths, and NoOps. They are functional decomposition or domain-driven design, well-defined interfaces, explicitly published interface, single responsibility principle, and potentially polyglot. Each service is fully autonomous and full-stack. Thus changing a service implementation has no impact to other services as they communicate using well-defined interfaces. There are several advantages of such an application, but its not a free lunch and requires a significant effort in NoOps. But lets say you understand the required effort, or at least some pieces of it, that is required to build such an application and willing to take a jump. What do you do? What is your approach for architecting such applications? Are there any design patterns on how these microservices work with each other?
- Microservices -