Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
Applications are not getting simpler and less complex nowadays. As an industry, we are advancing how we architect our systems and deliver services for these applications to become more efficient and effective.
Breaking down your application into microservices can largely decrease complexity of developing and deploying single decoupled components. At the same time the overall system becomes more complex since more components are involved.
Good software architecture is essential to building great software. What is software architecture all about?
This is the first article in the following series of articles on software architecture:
I’m talking as someone who has actually implemented multiple distributed transaction systems. People moving to microservices are now discovering a lot of the challenges and hurdles of distributed systems and it is only natural to want to go back to the cozy transactional world, where you can reason about things properly.
This post is in response to this article: Microservices and distributed transactions, which I read with interest, because it isn’t often that a post will refute it’s own premise with the very first statement.
A long time ago, before I dove into software development, I was a Materials Engineering student at the University of Toronto. Having gloriously arrived on a scholarship out of high school, I was unceremoniously kicked out 18 months or so later for ridiculously bad performance (I think my average was below 40). Nonetheless, while occasionally showing up for class, I learned a few things from one of the few professors who knew how to teach. Almost 20 years later, I draw value from those lessons when thinking about software architecture.
Iron is transformed into steel by adding new elements. This seemingly contrarian step adds strength by reducing purity. Steel Engineers are careful in choosing the right combination of complementary elements to craft a material far greater than its parts.
This tutorial is the second part of a series: Building microservices through Event Driven Architecture.
During this journey, I will implement the domain model: EduSync.Speech.Domain,
Image source: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
Today, architectures such as the onion or hexagonal patterns play an important role in the testability and maintenance of code, its independence from external frameworks, etc. In this tutorial, I will show you how to use clean architecture, with methods and tools such as Domain-Driven Design (DDD), Test (Behavior) Driven Development (TDD), CQRS, Event Sourcing, Containerization, OAuth2, and Oidc to build a microservices architecture.
There has been much buzz about micro front-ends as of late, but have you been wondering what it is? Well, allow us to explain. Simply put, a micro front-end is akin to the concept of microservices, just applied to a web app's front-end. With micro front-ends, web apps are integrated into modules to achieve a specific business-related need that is owned by various teams. Also, every team develops the feature end-to-end, from the UI, all the way to the database and backend. As you can see, the concept remains the same as with microservices — you make smaller independent services work in unison to serve a more significant application.
More often than not, when organizations take on a microservice architecture on the backend, the front-end apps are left as monoliths. What is that, you ask? Well, unified architecture refers to when you use a single team to build web apps with unique technology, and all of the development is completed altogether. Here the backend is organized following the business's needs, but the front-end continues to be jammed into just one app. It can throw up various issues over time. Thankfully, micro front-end architectures allow the entire application to be divided up across the complete stack according to the business domain. It provides the front-end development teams with similar levels of speed, testability, and flexibility as the ones available to the backend team via microservices.
When designing distributed systems it's important to understand that explicit design decisions must be made to enable scalability within components. These applications must be engineered from the beginning with the requirement to meet anticipated needs with options that facilitate future growth. We build our systems in anticipation of scaling because we anticipate the platform will grow, which means more users, features, or data.
This is the first article in a series of posts where we will discuss topics which include:
One of the primary problems facing enterprises is the problem of moving from monolith to microservices. The larger the enterprise, the bigger their monolithic applications become, and it gets harder to refactor them into a microservices architecture.
Everyone seems to agree on the benefits of microservices. We covered this topic at some length in this post. However, not many seem to agree on how to undertake the migration journey. Too often, the decision-making process turns into a chicken-and-egg problem. The bigger the monolith, the bigger the stakeholders' and management's footprint becomes. Too much management often leads to decision paralysis and, ultimately, the journey ends up as a mess.
Microservices are one of the biggest buzzwords of recent years. However, it turns out that it is a bit like teenage sex: everyone talks about it, but nobody really knows how to do it. What does it take to make good use of this architecture? What conditions do we have to meet so that it’s something more than just an item on your CV? Read the article to find out.
Several years ago, conferences were all about Service Oriented Architecture. In a nutshell, it consists of building large systems with many logically divided services integrated with each other. The idea was to eliminate the main problems related to monolithic architecture. Most SOA implementations were based on, or shifted over time toward, the Enterprise Service Bus. The bus was responsible for communication routing, document mapping, handling different types of endpoints, auditing, and security. The idea was noble, but the versatility of the solution turned out to be a double-edged sword. After some time, the bus turned into another monolith. Centralization, bottlenecks, both in terms of development and efficiency, and a single point of failure contributed to the growing criticism of the solution. I know cases where a 60-80-person team working on the bus turned out to be insufficient and a part of the communication had to be point-to-point so as not to block business projects.
As enterprises modify and optimize their architecture for the customer-centric digital commerce boom, many enterprises lack the institutional knowledge necessary to quickly make the transformation. Here at commercetools, we have built a cloud-first API only commerce architecture that most companies wish to emulate within their own ecosystem. Thus, our customers frequently ask us to help guide them in their transformation.
This leaves us in a difficult position. Developers are always trying to find the balance between extremely opinionated systems and being forced to reinvent the wheel. commercetools strives to allow developers total flexibility when leveraging its API, from programming language, to SDK options, to choosing REST or GraphQL. The unopinionated nature of commercetools leaves developers with the responsibility of choosing frameworks, cloud architecture, and configuring all the tooling necessary in between.
Welcome back! If you missed Part 1, you can check it out here.
I hope that by now you are pretty much clear about what a microservice is and have started analyzing the strengths and weaknesses of it. I tried to keep it simple by giving just an overview of what a microservice should look like, but there’s a lot more to it that I won’t be covering in this series. Though I would like to mention a key difference between microservices and SOA (Service Oriented Architecture). Yes, the two are not the same and that is because SOA does not talk about the service deployment and it is the reason that when we build a system using SOA we end up building it in a monolithic style, where all the services are deployed altogether as one application. On the other hand, microservices are a subset of SOA, but they require that each of the services is independently deployed, meaning that they can be put on many different machines and any number of copies of the individual services could be deployed.
Microservices are not new in the market, they have been a part of our day to day life for a while now, so here in this post, I would like to share with you my understanding of what microservices are and what the Saga Pattern is, which is widely used with the microservices. We will start with what exactly we mean when we say: (i) we need a microservice, (ii) what it means to be reactive, and then (iii) dig into the concept of Saga patterns, with respect to a distributed system along with an easy to understand real-life example.
So let’s get started.
We recently re-designed our API Client UI from scratch. In this post, I want to share best practices on handling Access Secrets, and how these influenced our new design.
Every microservice, every front-end, every developer, and whoever else directly accesses your API should get its own API Client. This allows request correlation and the ability to revoke an API Client quickly when you find out it has been leaked. But most importantly, it is the basis for the principle of least privilege.
By now, most eBay core business flows have gone through the journey of implementing Experience Service-based multi-screen application solutions, where web and mobile native app user interfaces are composed of one or more modules, and Experience Services directly returns these modules to clients with content synthesized from backend data sources, localized and formatted, and ready for rendering and user interaction. This article outlines a plan to move more modules to a shared environment.
This architecture offers benefits for each each business flow or domain by providing: