Posted on

APIs: Our Legacy from Flawed 1960’s Thinking

Object-Oriented Programming and Design principles have now existed for over 50 years, so it seems odd that apparently, no one has noticed the substantial flaw in Object-Oriented Design that has existed since the very beginning. We are instead told that Object-Oriented (OO) Design principals have won the day, as they provide a programmatic mirror image of the real-world scenarios they are intended to reflect. If we look a little deeper, OO Design is in fact completely detached from the world that it is intended to model. Whilst it is obviously true that the world consists of objects — known and unknown, real and abstract — the unimaginable flaw in OO Design fundamentals that seems to remain undetected until this day is that calling objects can never have complete mastery of the Interfaces of the objects they call: objects can only ever be masters of their own Interface — of themselves.

Example

Let’s imagine a Customer Object in negotiations with a SalesContact Object, in any given IT Landscape. OO Design asks us to pretend that the Customer Object has perfect mastery of the SalesContact Object Interface, and therefore knows exactly how to call the relevant RequestQuotation method of the SalesContact Object: having already guessed at the name of that method, its latest publicly-available version, and based upon the false hope that the definition of the RequestQuotation method will not change over time. The obvious reality is that the Customer Object can only guess at the Interface of the SalesContact Object, and hope that this Interface does not change in the short-term (e.g. as the product range offered by the SalesContact becomes more developed, and therefore more complex). Add to this the fact that the very same Customer Object may need to exchange with several different SalesContact Objects in several different departments, not all using the same Interface Version or even the same Interface — the same API — and we must consider that the OO Design philosophy, as it stands today, is massively flawed.

Posted on

Microservices and Service Mesh at A Glance

What Is a Service Mesh?

As enterprises are moving from monolithic to microservices/distributed microservices to achieve more resiliency and performance, service mesh has a key role in that kind of digital transformation.

A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud-native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware. Service mesh has mainly two major components — the control plane and the data plane, which decouples the business logic from technical complexities.

Posted on

Rethinking Serverless Architectures With Eventbridge

Here's the context of how the need for AWS Eventbridge came to be.

As the march of technology is never-ending, the only constant we can expect is change. This is especially true considering the strides that serverless has made in the industry, especially with the release of the AWS Lambda back in 2014. Upon its release, AWS Lambda was quick to take front and center position in the FaaS services making up the core of serverless applications. It was rightly heralded as one of the most important releases within the domain. This further lead to an array of best practices dictating how applications were built using FaaS services achieving serverless capabilities. 

You may also enjoy:  Explaining Eventbridge Amidst the Hype

However, as the course of technology meanders in its ongoing path, new innovations are constantly redefining the way we build applications. One such innovative service announced this year was AWS EventBridge, and its release has since caused an uproar in the domain of serverless. Many blogs and posts within the community that followed the announcement characterized it as the most important announcement after the release of AWS Lambda. 

Posted on

7 Myths About Web Services

Despite the popularity of SOA and Microservice Architectures, some technological and implementation details are often missunderstood or incorrect interpreted. In this article, we will review seven facts about Web Services that can help developers to better understand the concepts and also to better prepare for interview questions if needed. 

You may also The HTTP Series (Part 1): Overview of the Basic Concepts.

HTTP Is Absolutely Required for RESTful Services

HTTP is not formally required for RESTful web services, but if HTTP methods are used, their formal meaning should be strictly followed so that without additional effort the clients can understand the API (e.g. do not use POST to update data, it is supposed to only create resources and is not idempotent by nature).

Posted on

Microservices Architectures: Microservices vs. SOA

Microservices architectures are very popular today. In this article, we take a look at how microservices architectures are different from Service Oriented Architectures (SOA).

Introduction to Cloud and Microservices: Challenges and Advantages

This is the last article in a series of five articles on cloud and microservices. The previous four can be found here:

Posted on

Microservices: Are They for Me?

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.

Nothing New Under the Sun

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.

Posted on

Microservices and the Saga Pattern, Part 2

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.

Posted on

Microservices and the Saga Pattern, Part 1

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.