InfoQ Homepage Microservices Content on InfoQ
-
Strategies for Decomposing a System into Microservices
A couple of years ago, Vladik Khononov and his team decided to start using microservices, but a few months later they found themselves in a huge mess. They concentrated on new cool technologies instead of thinking about how to decompose a system into microservices — finding the boundaries and where different functionalities should be located among these boundaries.
-
Observability and Microservices: The Need for Effective Tracing and Metrics
Zach Jory has written an article discussing how microservices and service mesh implementations need observability to ensure that developers can build cloud-native applications which scale and can be more easily managed. This ties into a number of articles and interviews we have spoken about over recent months too.
-
Instana Extends AI Application Monitoring to AWS Lambda
Instana, a cloud-native provider of artificial intelligence based monitoring tools for dynamic containerized microservice applications, has extended support to include AWS Lambda, a serverless computing platform and also announced availability through the AWS Marketplace.
-
Microservices to Not Reach Adopt Ring in ThoughtWorks Technology Radar
Whilst microservices come with many benefits over traditional monolithic applications, they can also introduce additional complexity into an organisation, writes Rebecca Parsons, chief technology officer at ThoughtWorks. Because of these tradeoffs, she does not believe that microservices should always be the default architecture choice for a software application.
-
Q&A with Bob McWhirter on WildFly Swarm Rename to Thorntail
In early 2015, Red Hat released Wildfly Swarm, which allows Java EE based applications to run as microservices. The approach allowed developers to migrate Java EE monolith applications to microservices by creating an uber-JAR that not only contains the Java program but embeds its dependencies as well. Wildfly Swarm was recently renamed to Thorntail.
-
Microservices and Site Reliability Engineering
A recent article talks about how the complexities introduced by microservices initially seem at odds with the concept of Site Reliability Engineering (SRE), and how companies such as Google are tackling that to ensure that whilst development groups can continue to embrace microservices, they and their SRE teams have the necessary tools and understandings to make them work well together.
-
Cloud Native Java Has A New Home: Jakarta EE
Mike Milinkovich, executive director at the Eclipse Foundation, introduced a new Eclipse governance model and roadmap for Jakarta EE at this year’s JAX conference. Based on a recent survey of over 1800 Java developers, the new governance model will focus on support for cloud native application development and faster release cycles. Milinkovich spoke with InfoQ on the future of Jakarta EE.
-
The Future of Microservices as the IT World Changes: Uwe Friedrichsen at microXchg Berlin
You have finally mastered Microservices, including Docker and Kubernetes, and some other new cool trends. But are you prepared for the future, Uwe Friedrichsen asked in his presentation at microXchg 2018 in Berlin where he explored the future of IT and the consequences for microservices.
-
Designing Reactive Systems Using DDD, Event Storming and Actors
Domain-driven design (DDD) is often used for finding boundaries (bounded contexts) around microservices. But everything in domain-driven design (DDD) is not good for microservice, Lutz Huehnken claimed in a presentation at microxchg 2018 in Berlin where he discussed how DDD, Event Storming and the Akka-based Lagom framework can be used to build reactive systems.
-
The Maturity of Microservices: MicroXchg Berlin Panel Discussion
In the microservices panel at microXchg 2018 in Berlin, Susanne Kaiser, together with the panel, consisting of Stefan Tilkov, Chris Richardson, Elisabeth Engel and Daniel Bryant, discussed the state of microservices as of today and whether the hype is over — is microservices now a mature technique or is serverless the next step?
-
Stefan Tilkov at microXchg Berlin: Microservice Patterns and Antipatterns
In his presentation at microXchg 2018 in Berlin, Stefan Tilkov explored patterns and antipatterns in microservice projects from his perspective, including Evolutionary Architecture, Decoupling Illusion, Distributed Monolith and Entity Service. He especially noted that some of the patterns he considers to be patterns, other people may see as antipatterns, and the other way around.
-
Monitoring Microservices at Scale at Crisp
Crisp’s engineering team shared their experience in monitoring their microservices stack. Vigil, their open sourced project in Rust, is a set of pull/push probes to collect health data with support for multiple languages, a status dashboard and integration with some external alerting tools.
-
Common Pitfalls in Microservice Integration: Bernd Rücker at QCon London
In a microservices architecture, every microservice is a separate application, with its own data storage and communicating over a network. This creates an environment that is highly distributed, and with that come challenges, Bernd Rücker explained in his presentation at QCon London 2018, exploring common pitfalls in microservice integration and solutions that include workflow engines.
-
The Future of Microservices and Distributed Systems: QCon London Microservices Panel Discussion
In the microservices panel at QCon London 2018, track host Sam Newman together with Susanne Kaiser, Guy Podjarny, Idit Levine and Mark Burgess, discussed how the service technology as we see it today will change, and how we will build systems in the future. They believe microservices will continue to exist but will evolve into becoming a base for other techniques like serverless architectures.
-
Fred George on Solving Fuzzy Problems
In the Digital Transformation day at the Agile India conference Fred George gave a talk on how the way we solve programming problems needs to change when dealing with what he calls “fuzzy problems” where the speed of response is more important than any other factor. The development “team” in those environments consists of a single developer working directly with a customer deploying frequently