What is a service catalog? And why would I want one?
Every team building microservices or a distributed system should have a service catalog.
Teams that are building distributed systems quickly find themselves in a situation where people throughout the org – from the CTO & Engineering Managers through to the developers, testers, SREs, and Infosec – need to understand what parts make up the system, how they fit together, and who is looking after them. This is what a service catalog provides.
A service catalog lists all the components that make up a system – both those managed by the organisation and any external dependencies and clients – and documents who owns them, how they’re designed, what APIs they offer and use, and where to find their code. A good service catalog incorporates the fact that software is part of a socio-technical system: the software is only one part of the picture, and the people that develop it and look after it are a crucial element to understanding how everything fits together.
Without a service catalog, teams building distributed systems will find inefficiencies creeping in everywhere: a developer who needs to find a service’s code, a tester who needs to read its API docs, an SRE who needs to contact the owners of a service, an Engineering Lead who needs a diagram of the system – all these common needs will trigger an ad hoc discovery process that could waste precious minutes, hours, or days. With a service catalog, all these tasks can be completed instantly by just looking up the information in the centralised catalog.
What is an architecture model? And why would I want one?
Some tools automatically produce architecture diagrams by looking at your cloud account’s infrastructure and putting everything they find into a diagram. Archium takes a smarter approach.
Archium reverse engineers the structure of your architecture from your distributed tracing, and stores a representation of that structure as an abstract model in its database.
Once you have a model, you can generate hundreds of different diagrams by focusing the Archium service map on different parts of your system. We can also use the model to get simple answers to complex questions, like “Which services have to be up when someone presses the ‘Buy’ button?” That’s the power of having an architecture model.
Is Archium an observability tool?
Software products branded as ‘Observability’ tools tend to focus heavily on real-time operational support for distributed systems, helping teams to monitor and investigate patterns of traffic, errors, and response times / performance.
Archium instead focuses on architecture observability. While other tools observe the operation of the system, Archium helps teams observe the design of a system, providing insight throughout the planning, design, and testing phases of their SDLC, as well as operation.
Archium doesn’t provide real-time monitoring or metrics – there are already plenty of great tools for that. What it does do is keep track of your system architecture in near real-time, adding new components and APIs to your model within hours of them first receiving traffic.
Does Archium need access to my system?
If you want to automatically build an architecture model (which we really think you should!), Archium will need access to your distributed tracer that receives telemetry from your system. It doesn’t need access to any other part of your system.
Can we use Archium without distributed tracing?
Yep! If you don’t have distributed tracing yet, you can still use Archium as a service catalog where.
To build your catalog without tracing, you’ll need to have your team add data about your system manually, or write some scripts to populate the catalog via our API. And you can always set Archium up to build an architecture model from distributed tracing later.
If you have a microservices architecture and you don’t have comprehensive distributed tracing in place yet, we highly recommend making it a top priority for your team, whether you plan to use Archium or not.
One of the biggest benefits of Archium is automating the construction of an architecture model. Doing this automatically means your service catalog and architecture knowledge base can be comprehensive, up to date, and more detailed than you would ever bother documenting by hand.
We sometimes get asked if Archium can build an architecture model from logs instead of traces. While we’d love to have more options for building a detailed architecture model, the truth is without the rich data about API causality found in distributed tracing, it’s just not possible to do that well.
Do I need to change my system for Archium to work?
No. Archium itself doesn’t require your system to be instrumented with any proprietary code.
If you want to automatically build an architecture model, Archium does require that your system is instrumented with distributed tracing, and that Archium can get access to your traces. To get the best results, your tracing should comprehensively cover all components and features of your system.
Does Archium have an API?
Absolutely. You can automate almost any feature of Archium you want by generating an API key and interfacing with our REST API. Our API spec is kept up-to-date and available on our exclusive customer knowledge base.
Can Archium automatically model an on-premise system?
It’s definitely possible. If there’s a way to get Archium access to distributed tracing data, then it can model the system being traced.
What is distributed tracing?
Distributed tracing is a type of monitoring used in distributed systems to trace the sequence of actions taken to respond to an individual request. By propagating special pieces of data called trace context between each service that handles a request, a distributed tracer can reconstruct the path of all the interactions in the system for that request, as well as recording the time incurred in each service and other data that may be useful for filtering and investigating the system’s behaviour.
Distributed tracers may be open source (e.g. Zipkin, Jaeger, Apache Skywalking), part of a cloud computing platform (e.g. AWS X-Ray, Azure Monitor, Google Cloud Trace), or offered as a third-party SaaS or on-premise product (e.g. AppDynamics, Dyntrace, Honeycomb, Instana, Lightstep, New Relic, Splunk APM… and too many others to name!). Archium integrates with several of these products today, and we’ll be adding more over time as we hear demand.
How do I say “Archium”?
Just remember it starts like architecture, and rhymes with medium!
It’s pronounced AR-key-uhm.