Making Your Enterprise Application 100% Serverless with AWS

There was an era in which we all fussed about cloud computing; however, right now the hype is mainly about serverless computing. In this article, I will brief you about serverless computing and share my experience in working with some serverless technologies that my team and I used to develop enterprise solutions.

My list of topics are as follows – each will have a quick introduction the technology used along with some web links which we looked at when integrating these into our final solution.

  • Serverless Computing
  • Requirement
  • Architecture & AWS Services
  • Lambda Functions for Microservices and BFF
  • API Gateway
  • Cognito for User Federation
  • ECS Fargate for Long Running Tasks
  • AWS Code Pipeline & Code Build for CI/CD
  • Other Services

[Please visit this link to get details on each of the above topics]

Read More

Microservices Architecture Implementation: Tech / Tool Stack Map

There are different tool stacks like nodeJs, Spring cloud which we can use to build microservice solutions. Since I’m having a Java background, in this post we will look how the spring cloud solution will help us to develop comprehensive microservices solution. This tool set is applied in my working environment and it’s running smoothly in Production setup.

Due to excellent tool support and easy integration capabilities Spring cloud with spring boot framework makes developer life stress-free.

Below diagram illustrates the full component stack. Will give you a very high level usage of each component in this post. Later we can dig deep in to each component.

Microservices architecture solutions implementation using Java framework: Spring Boot / Spring Cloud Components

  • RAML / Swagger / Thrift : Used to design Contract-First microservices
  • Zuul : Edge Server, Reverse proxy server. API gateway or gate keeper for external parties
  • Eureka : Act as Service registry & discovery component
  • Ribbon : Load balancer
  • Spring Cloud Config : Centralized configuration server for the MSA solution
  • OAuth2 / JWT : Security mechanisms which can be integrated with microservices
  • Hystrix : Monitoring dashboard for the services and fault tolerance configuration component
  • Redis / memchached : Distributed caching mechanisms
  • AMQP / MQTT / STOMP : Messaging protocols for asynchronous communication
  • REST / Thrift : Messaging mechanisms for synchronous communications
  • Docker / OpenStack : Deployment architectures for our microservices
  • Tomcat / Jetty : In-build servlet containers in Spring boot


With all the above tools and components we can build a production ready microservice solution in rapid speed. In the coming posts let’s try to grab more knowledge in those areas.



Read More

How Microservices fitting in Enterprise SOA Solutions

In previous posts we discussed on different topics of Service Oriented Architecture and Microservices. In this post we will discuss how Microservices moving in to the traditional SOA solutions.

In software engineering, SDLC (System Development Life Cycle) is a well know process. Similarly when we want to develop SOA solutions, there is similar process which is illustrated in the below diagram.

In the Service Oriented Analysis and Design stages, microservices comes in to the picture.  Before we proceed let’s get a quick introduction to microservices. In SOA world microservice represent a specific performance / reliability requirement (business process) in a SOA solution. Its holds a distinct implementation environment optimized to support special processing demands that required for performance and reliability needs. Microservice is an independent service, however when a microservice needs to access other resources (services), those resources can either be replicated or redundantly implemented so that they remain part of the microservice’s local processing scope. Therefore, when it is decided that a microservice needs to compose another service, the composed service may be redundantly implemented and deployed together with the microservice.


Service Analysis and Modeling Process

Now let’s check how microservices are produced in a SOA solution on a given Business Process.


Step 1 | Analysis of the Business Process:

Main goal of this step is to decompose the business process to smaller processors. To achieve this we can follow the below steps

  • Identify main processors in the business process
  • Breakdown each main process in to small processes
  • Draw the detail business process flow diagram
  • Identify small processes which cannot be automated or should not be automated. Those processes should only handle through a manual process. So remove them from the list of process which are candidates for service implementation


Step 2 | Define Entity Services:

From the list of processes which are candidates’ service implementation, find out reusable agnostic services candidates and its capabilities.  Those services can be categorized as entity services.


Step 3 | Define Task Services:

These are the services which has process specific logic (non-agnostic). After identifying the entity services, the remaining can be categorized under task service. Normally we can find business rules, conditional logic which is specific to a process in this kind of services.


Step 4 | Apply Service Orientation:

Revisit the services which we have categorized and try to apply service orientation principles on them. Service loose coupling, Service abstraction and Service autonomy to those services.


Step 5 | Identify Service Composition Candidates:

In this step, we will look at the entity and task services that we captured during earlier stages and check whether those are candidates for service compositions.


Step 6 | Analyze the processing requirements:

For each process / sub process we need to follow the following steps to identify special requirements

  • What are the processing logic required in each service
  • Did we identified them earlier or do we need to redevelop them
  • What are the external resources we need to access via our services (DB, Message Brokers, Legacy systems)
  • Any logic critical for performance and reliability
    • This is the point where need of microservices comes in to picture in SOA solution
    • By producing performance and reliability critical services as microservices, we can ensure other services won’t have any impact from those performance critical services. Since those are run independently


Step 7 | Define Utility Services:

From the agnostic processing logic which we identified earlier, check if there are any reusable utility services. For example logging services and notification services.


Step 8 | Define microservices candidates:

Revisit the non-agnostic process logic which we identified earlier and determine any of the logic can be represent as microservices. Ideal candidate for a microservice would be

  • Volatile requirement
  • Performance requirement
  • Runtime reliability and failover requirement
  • Service visioning and deployment requirement


Step 9 | Apply service orientation:

As we did in the step four, repeat the same process to utility and microservices which we identified earlier


Step 10 | Revisit the service composition candidates:

Check whether we can use the microservices and utility services for other service requirements


That’s pretty much it, on the process of analysis and design stage of services in a SOA solution. So we can clearly see where the microservices coming in to play in the SOA solution development process.



Read More

Is Microservices Architecture a sub set of SOA? (Understanding Microservices Architecture by wearing the Developers Thinking Hat)

In the previous posts we looked in to the basic concepts of SOA. Thought of moving to a new term in the technology world called Microservices Architecture. Actually the term is the only thing which is new to SOA world. The concepts behind the microservices architecture came with SOA. However if you’re not familiar with SOA and compare the microservices architecture with Monolithic applications development then this would be a new concept for you. Assuming you have the knowledge in SOA, we will justify the above argument which is Microservices Architecture is a sub set of SOA.

What is Microservices Architecture?

Microservices architectural style is an approach of developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies. – “Martin, Fowler”

Let us concentrate on the definition of microservices architecture and discuss about each special characteristics.

The concept “small services which build around business capabilities”, is a concept we discussed under SOA. Which is Agnostic Logic and Entity Service concept in SOA. Those services are reusable, also concentrate on single small business problem.

The statement “Developing single application as a suite of small services” is yet another well establish concept in SOA known as “Service Composition”. There we have a Service Inventory which is a collection of reusable small services which will help to compose large services / applications.

The newly introduce concept on microservices architecture when compare to SOA is; microservices is individually deployable services which make them very easy to apply continuous integration and deployment. Where in SOA we deploy our services in shared resources. Microservices architecture is more driven by DevOps practices. Mostly deployed in cloud infrastructure, each service has the capability to auto scaling in built. With the immerging container technologies like Docker and surrounding technologies like Mesos and Kubernates will ensure the deploying micro services will be more unwind than ever. This concept will maximize the decoupling of logic and in addition the platform they are deployed. In the long run microservices architecture will minimize the change management cost compare to traditional SOA.

However if you have properly deign and implemented your SOA solution then you should be able to easily deploy your services independently in Tomcat / Nginx application servers across the nodes in your cluster too. Which will cover the key feature in micro services architecture.
In SOA, ESB and BPEL orchestration software plays a major role in building communication structures between different systems enterprise applications. Let’s see how microservices architecture replaces those tools.


ESB / BPEL Tools vs Smart Endpoints and dump pipes

Enterprise Service Bus (ESB) main capabilities are message routing, choreography, transformation, and applying business rules. In the microservices architecture ESB capabilities are covered through smart end points and dump pipes. REST protocol with different end points (smart endpoints) which has appropriate logic behind it will ensure the covering of ESB and BPEL orchestration capabilities we see in SOA. Application of a lightweight message bus act as the dump pipes in microservices architecture. It can be simply implemented using tools like RabbitMQ. The key added feature from dump pipes is reliable asynchronous messaging between services which is also common in SOA.

Below diagram illustrate the how microservices architecture differentiate from SOA.


So we can clearly see microservices architecture does not have much difference compare to SOA other than the deployment platform. Further as many articles express; “Microservices architecture is a design pattern of SOA” and Microservices architecture is a new term introduced to latch a new look to very old concept called SOA.



Read More