Use case · Web & apps
Microservices hosting
A microservices architecture builds an application as many small, independent services that communicate over the network. Hosting it means running many services — often in containers with orchestration — with fast inter-service networking, independent scaling, and resilience so one service's failure does not cascade. Dedicated, EU-hosted infrastructure gives control, performance, and European sovereignty; microservices are not always simpler than a monolith.
Key points
- A microservices architecture builds an application as many small, independent services.
- The services communicate over the network, so inter-service networking matters.
- Services can be scaled independently, each according to its own load.
- Resilience matters so one service's failure doesn't cascade through the system.
- Microservices add complexity, and aren't always the right choice over a monolith.
What is a microservices architecture, and what does it need?
A microservices architecture builds an application as many small, independent services, each responsible for part of the application's functionality, communicating with one another over the network — in contrast to a monolith, where the application is one large program. Each microservice can be developed, deployed, and scaled independently, which offers flexibility, but it also means the application becomes a distributed system of many parts that must work together. Hosting a microservices application therefore means running many services, providing the networking they communicate over, allowing them to scale independently, and keeping the whole resilient despite its many parts.
This distributed nature shapes what microservices hosting must provide. Where a monolith runs as one program, a microservices application runs as many services that must be deployed, connected, scaled, and kept running together, which is more involved. The infrastructure has to run the many services — often using containers and orchestration — provide fast networking between them, support their independent scaling, and help the system stay resilient when individual services fail. This page focuses on hosting microservices; container orchestration platforms are covered on their own pages, while what follows attends to what a microservices architecture needs from its infrastructure, including honestly when it is and is not the right choice.
Running many services: containers and orchestration
Microservices are commonly run in containers, with an orchestration system coordinating them, because many independent services need a consistent way to be packaged, deployed, and managed. Containers package each service with what it needs to run, so services can be deployed consistently across infrastructure; and an orchestration system manages running the many containers — placing them on servers, restarting failed ones, and scaling them. This combination has become the common way to run microservices, since it addresses the challenge of deploying and managing many services in a consistent, automated way.
Hosting microservices therefore often means providing the infrastructure a container orchestration platform runs on — the servers on which the containers are placed, with the resources the services need. The orchestration coordinates the containers across this infrastructure, and the infrastructure must provide the compute, memory, and networking the services and their orchestration require. Whether an organisation runs a full orchestration platform or a simpler container setup, the infrastructure underneath provides the foundation. We provide dedicated infrastructure on which microservices and their orchestration run — servers sized for the services, connected and resourced for running many containers — so that a microservices application has a solid foundation to run its many services on.
Inter-service communication: networking between services
In a microservices architecture, the services communicate with one another over the network to work together, so the networking between services is important in a way it is not for a monolith, whose parts communicate within one program. A request to a microservices application may involve several services calling one another, each call crossing the network, so the speed and reliability of the networking between services affects the application's performance and reliability. Slow or unreliable inter-service networking makes the whole application slower and more fragile, since it depends on the many calls between services.
This makes fast, reliable networking between the services a real consideration in hosting microservices. The services should be able to communicate quickly and dependably, so that the network calls between them do not become a bottleneck or a source of failures. Running the services on infrastructure with good networking between them supports this, keeping inter-service communication fast and reliable. We provide infrastructure with the fast, reliable networking microservices need between their services, so that the inter-service communication a microservices application depends on is quick and dependable, rather than becoming a drag on an architecture whose parts must constantly talk to one another over the network.
Independent scaling of services
A significant benefit of microservices is that services can be scaled independently, each according to its own load, rather than scaling the whole application together as a monolith must. Different parts of an application often have different load — one service may be heavily used while another is not — and microservices let each be scaled to its own need, running more instances of a busy service without scaling the rest. This can use resources more efficiently than scaling a whole monolith to meet the load on its busiest part, since only the services that need more capacity get it.
Supporting independent scaling means infrastructure and orchestration that can run more or fewer instances of each service as its load requires. The orchestration scales services by running more instances of busy ones across the infrastructure, which must have the capacity for the instances the services need at their various loads. This lets the application's resource use track the actual load on each of its parts. We provide infrastructure with the capacity and flexibility independent scaling needs, so that a microservices application can scale each service to its own load — an advantage of the architecture — with the infrastructure providing the resources the services require as their individual demands vary.
Resilience: isolating failures between services
A microservices architecture can be resilient, because the independence of services means one service's failure need not bring down the whole application, if the system is designed to isolate failures. When services are independent, a failure in one can be contained — the rest of the application continues, degrading gracefully rather than failing entirely — provided the application handles the failure of a service without cascading. This potential for resilience through isolation is one of the arguments for microservices, though it depends on designing the system to handle service failures.
The infrastructure supports this resilience by running services in a way that isolates and recovers them. Orchestration restarts failed service instances and can run services across multiple servers, so the failure of one instance or server does not take down a service; and the isolation of services from one another limits how a failure spreads. Realising resilience also depends on the application handling service failures gracefully, but the infrastructure and orchestration provide a foundation. We provide infrastructure that supports running microservices resiliently — with the redundancy and recovery orchestration across multiple servers provides — so that a well-designed microservices application can isolate failures and stay largely available when individual services fail.
Observability: understanding a distributed system
A microservices application is a distributed system of many parts, which makes understanding what it is doing — observability — more challenging and more important than for a monolith. When a request flows through several services, understanding the application's behaviour, diagnosing problems, and knowing how it is performing requires visibility across all the services involved, since no single service tells the whole story. This makes observability — collecting logs, metrics, and traces across the services — a real need for operating microservices, so that the distributed system can be understood and managed.
Observability is supported by infrastructure that runs the monitoring and logging a microservices system needs to be understood. Collecting and storing logs and metrics from many services, and tracing requests across them, involves infrastructure to run and hold that monitoring data. For a microservices application, this observability is important to operating it well, given how distributed it is. We provide infrastructure that supports the observability microservices need — a place for the monitoring, logging, and tracing that make a distributed system understandable to run — so that a microservices application can be operated with the visibility across its many services that managing a distributed system requires.
Microservices or a monolith? — and where we fit
The honest position is that microservices are not always the right choice, because their benefits come with real complexity, and for many applications a monolith is simpler and sufficient. Microservices offer independent deployment, scaling, and resilience, which are valuable at scale and for large teams, but they turn an application into a distributed system, with the added complexity of inter-service networking, orchestration, distributed failures, and observability. For many applications, especially smaller ones or those without the scale or team size that make microservices pay off, a monolith is simpler to build, deploy, and operate, and switching to microservices prematurely adds complexity for little gain. The right choice depends on the application, its scale, and the team, and we will not pretend microservices are always better.
Where we fit is providing the infrastructure a microservices application runs on, when microservices are the right choice: dedicated servers with fast inter-service networking, capacity for many containers and their orchestration, and support for the scaling, resilience, and observability microservices need — in EU datacenters under European jurisdiction, keeping the application's data sovereign. We provide the infrastructure foundation, not a managed platform that operates your services for you, and we are candid that if a monolith suits your application better, that is a fine choice we also host. We are the dedicated, sovereign infrastructure on which you run your architecture — microservices or monolith — suited to those who want control, performance, and European sovereignty. If microservices fit your needs, we can host them well.
Related use cases
See also
Questions
Microservices, answered plainly
Common questions about hosting for Microservices.
What is a microservices architecture?
An application built as many small, independent services, each responsible for part of the functionality, communicating over the network — in contrast to a monolith, where the application is one large program. Each service can be developed, deployed, and scaled independently, which offers flexibility, but makes the application a distributed system of many parts that must work together.
Are microservices always better than a monolith?
No. Microservices offer independent deployment, scaling, and resilience, valuable at scale and for large teams — but they add real complexity, turning an application into a distributed system with inter-service networking, orchestration, and observability to manage. For many applications, especially smaller ones, a monolith is simpler and sufficient. The right choice depends on the application, its scale, and the team.
Why does networking matter for microservices?
Because the services communicate over the network to work together, unlike a monolith whose parts communicate within one program. A single request may involve several services calling one another, each call crossing the network — so the speed and reliability of inter-service networking directly affects the application's performance and reliability. Fast, reliable networking between services matters.
Planning Microservices infrastructure?
We host dedicated, EU-sovereign infrastructure sized to your workload — and we will tell you plainly when something else fits better. Tell us what you're building.