Posted on

From SOA, to GraphQL, to Macroservices

SOA vs Microservices

Should you happen to be researching "Service-Oriented Architecture" (SOA) on the Internet today, the latest articles you are likely to find will typically be titled: "SOA vs microservices". Complicating the battle somewhat is that you will also find respected industry experts, such as Martin Fowler, stating that some “consider microservices to be one form of SOA, perhaps service orientation done right”.

Martin goes on to declare: “The problem…is that SOA means too many different things and that most of the time we come across something called 'SOA' [there is]…a focus on ESBs (Enterprise Service Buses) used to integrate monolithic applications. This common manifestation of SOA has led some microservice advocates to reject the SOA label entirely”. As such, for the remainder of this article, I will assume the use of ESB middleware as a fundamental characteristic of SOA landscapes, as well as representing the most fundamental distinction there is between SOA and REST.

Posted on

What Is a Microservice?

Microservices are a type of software architecture where the functionality of the application is broken up into smaller fragments to make it more resilient and scalable. We call these fragments “services”. Each service focuses only on a single functionality of the application and is isolated from the others, making each one of them independent. This means that your development teams can work separately on different services and avoid a complex orchestration between them.

These different services then communicate with each other through APIs or web services.

Posted on

How Choosing the Right Protocol Could Boost Your Profit

Introduction

High egress cost often comes out as a surprise. As David explains, egress cost could potentially go unnoticed at the initial stages of estimating expenses for a solution. In 2017, Apple paid more than $50 million as egress cost according to the post. Hence it is clear the size of the data matters for the cost-effectiveness of a solution. Data is transmitted between two or more systems via protocols. Since the early 90s protocols such as HyperText Transfer Protocol (HTTP) have been evolving. Further new protocols emerged over the years i.e gRPC, Thrift, Websockets, NATs, etc. There will be instances where multiple protocols would be compatible with a given paradigm, giving the option for solution designers to make a choice i.e if intended to send binary data between systems, one could choose HTTP as well as gRPC, Thrift, etc. This choice could be critical. This article would unveil the influence protocols have towards the data size by first evaluating a few selected protocols for similarities (since similarities give the option to choose between them). Subsequently will evaluate how these protocols differ semantically and articulate some hidden advantages they bring to reduce the data size transmitted over the network. Finally will present how reduced data size could increase revenue, discuss some of the roadblocks that would lead to making the wrong choice of protocol and possible ways to overcome them. 

Protocols Comparison

Differences make life easy, narrow down the scope, and gives a clear idea on the potential of the protocol. When things look similar it is up to the solution designer to choose the protocol. The familiarity of a protocol could influence giving precedence to it. “If everything is an apple, I’ll rather use the apple in my own tree”. While this choice would allow building a working solution, it might not be the most optimum. As a result, businesses would lose tons of revenue. The next sections in the article will elaborate on this. 

Posted on

Microservices in Practice: From Architecture to Deployment

Microservices is one of the most popular buzz-words in the field of software architecture. There are numerous learning materials on the fundamentals and benefits of microservices, but there are very few resources on how you can use microservices in real-world enterprise scenarios.

In this post, I'm going to cover the key architectural concepts of the Microservices Architecture (MSA) and how you can use those architectural principles in practice.

Posted on

Service-Oriented Architecture

Service-Oriented Architecture Overview

A service-oriented architecture (SOA) is an architectural pattern in computer software design in which application components provide services to other components via a communications protocol, typically over a network. The principles of service-orientation are independent of any product, vendor or technology.

SOA offerings should provide a solid solution to the problem of complex architecture and code redundancies, enabling efficient interoperability between systems, applications, and services.

Posted on

Tensile Strength

Software Architecture lessons From Materials Engineering

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.

Purposeful Diversity

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.

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.