What we’re about
[formerly London μServices (Microservices) User Group]
The Architectural Monolith’s days are numbered. As companies are becoming more and more agile, and see how they can now adapt in order to innovate and compete faster than their competition, software development teams are being forced to maintain and evolve large, monolithic applications at a pace of change that those architectures were never meant to withstand, let alone embrace!
Microservices are a new approach to architecting applications. They are simple, single-purpose, lightweight architectural components that enable you to deliver software faster. The microservice architectural approach also aims to lead to software that thrives on change while at the same time being secure, performant, and stable.
This meet up is for people interested in architecting, designing, deploying and maintaining micro service based software architectures.
If you want to advertise jobs to the group, read our policy here
Interested in speaking? See how we can help and how it works here
Got a talk? Send it to us here
Upcoming events (1)
See all- London Microservices Meetup - September 2023Trayport, London
## Agenda
18:15 Drinks, pizza and networking
19:00 First speaker
19:25 short break
19:35 Second speaker
20:00 finish
20:10 Drinks and informal networking - White Horse### Location
Trayport - 7th Floor, 9 Appold Street London EC2A 2AP,
## Speakers
EventBridge Toolbox
Ensuring best practices with event-driven architectures.
Ryan Schuller - Serverless developer at AleiosBuilding and evolving event-driven architectures often involves solving consistency challenges, especially at scale. Using an event broker such as Amazon EventBridge can help but it alone does not provide uniformity between producers and consumers. At Aleios, we've been working on an open-source toolbox that improves the developer experience and helps our teams bake in best practices
A Single Point of Failure May Not Always Be Bad
Ryota Sawada - Principal Engineer at UpsiderWith microservices, designing overall system interactions is crucial not to end up with a single point of failure. Even if we had flexible and scalable deployments, reliability may not be great due to one component not meeting the scalability requirements. But is a single point of failure really something to be removed entirely? In some scenarios especially around development, it can actually improve developer experience. We will look at a simple demo of having a Kubernetes cluster with SurrealDB as the central database for applications, and also some deployment to interact with it using mirrord. Both SurrealDB and mirrord are relatively new projects, and they are great examples of how single points of failures can be used as a part of system design.
