Why Micro Services ?

Why Micro Services ?

Micro Services are the next big thing in the modern software architecture and development. The distributed applications in the recent past changed the world of software outlook. Now the applications are developed, used, work and built differently. This caused the logical evolution of Micro Services. Some best examples of game changers in the software world are Git ( Distributed source control), Cloud computing (AWS, Azure, …), BitCoin (Distributed virtual currency).

Let’s begin our journey with understanding, What are Micro Services?

The Philosophy

The whole idea of Micro Service architecture is that they are small, focused and should be scaled.  

The Definition

The MicroService architectural style is an approach to 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 centralized management of these services, which may be written in different programming languages and use different data storage technologies.” – Fowler & Lewis, 2014.

This idea looks very similar to SOA. When I first heard about Micro Services, I thought they are just web Services and got many questions related to them. Some of them are as below
Why these services are called Micro Services?
What is the difference between these micro services and web Services ?
How different this world is different from SOA world?

Characteristics of Micro Service:

Do One thing well : Services should hide, how they work and do a single thing and do it well. The encapsulation is based on the business function of the service that it encapsulates the functional requirements.

Business Domain Centric : Each Service should align to the context with in the domain model for this to make sense in the domain and in the service architecture.

Decentralization : Every service should be decentralized and autonomous, so that each service can operate on its own schedule and priorities. Each service can be updated and deployed as fit.

Smart Endpoints and dumb pipes: This characteristic has come based on SOA, in SOA we have many products / ESB where we can define lot of logic in routing and transforming etc. Where as in Micro services the focus on login inside the service and the communication should happen very dumb like a REST / HTTP resource call to get to the service.   

Fail-Safe : Enterprise systems need to be smart, in that they fail in a way that doesn’t break things in unpredictable ways. Anticipate failure in everything, among with  validation of input and validation of data we send downstream.

Automation : Services should use automation which keeps management and operational support efficient. Employing large number of small services can become a mess if you do not embrace automation.

Principles of Micro Services – Encapsulation, Automation, Business Domain Centric, Isolation, Fail-safe and Observable.

Micro Service Vs Web Service:

The regular Web services are definitely different from Micro services. The regular web services support is based on protocols like HTTP / SOAP. These services are invented to solve the integration problems between application when we have polyglot technologies with different vendors/ applications. So, the aim of web services is to integrate or build a channel to communicate between these applications. Where as Micro services aim is NOT to integrate applications, perhaps to reduce the complexity of a monolithic application to micro services. This would give us re-use, maintainability, test-ability, scalability etc in the application.

Micro Services Vs SOA:

SOA started with very similar characteristics mentioned above, but the idea got converted when many vendors started introducing new features to SOA. Then we have a vendor lock-in problem now. We have lot of logic built in around the services NOT inside the services. So, Micro services are the out come of learning of SOA. Still, micro services are evolving. We might end up with very similar problems of SOA, if we are not cautious. Hope we would be able to use micro services the way they are explained.

Technology Support:

Here are the technology

Building Micro services with Spring Boot

Building Micro services with Drop Wizard

References:

Fowler & Lewis on MicroServices

Videos on MicroService Architecture

Advertisements
How to explain Cloud Computing to your Granny ?

How to explain Cloud Computing to your Granny ?

In my previous post I explained the characteristics of cloud computing, perhaps people say if you know something very well you should be able to explain the thing to your granny. If you could do it successfully then you know about this technology well.

I consider this correct, So I gave this attempt. Lets hope this will workout well for you as well. I hope this would be useful for some of you as well in understanding the concepts.

Lets discuss about the Service Models of Cloud computing. IaaS, PaaS, SaaS.

Lets try to explain these models to our Granny 😉

IaaS (Infrastructure as a Service)

If you have to build a house, what is that you need before you start constructing the house ? Foundation – which is the basic need to build in our case this is  If you don’t have sufficient infrastructure at your end, you will hire the Infrastructure from these cloud companies.

If you don’t have sufficient time and energy to build the foundation of the house, you will hire the labor to build it and pay them hourly basis. The same way you will pay for the infrastructure you have used either based on the number of cores / memory utilized.

Eg: Rackspace, VMWare

PaaS (Platform as a Service)

If you don’t want to build house or you don’t have budget to build a house what you would do? Most likely you would rent a house … right ? This is much cheaper option and you will get a ready house where you can live in immediately. still you might have to spend some money on furniture like Sofa, Fridge, TV, etc.

In the same way, the service provider would provide you the platforms like Google App Engine, Microsoft Azure, Red Hat’s OpenShift, provides the platform to you where you can write your own Apps and add-ons using given platform. These platforms offer you the basic building blocks for you to start your work quickly and scale easily.

SaaS (Software as a Service)

If you take the previous example, you might think of taking a fully furnished apartment for rent. So you don’t even need to develop your own software on the platform. Just use the software and pay as per you use. This again has many models based on the application for charge back, some applications charge per size, some per request etc. Like based on the furniture and amenities you have in your house the rent will be charged. Eg SaaS services are  Microsoft’s Office 365, Prezi.com and millions of software.

Hope you can try explaining cloud computing to your grand parents too.

Happy reading 🙂

Is Service Orientation a need for today’s Enterprise ?

Is Service Orientation a need for today’s Enterprise ?

As part of my learning, I started the SOA ( Service Oriented Architecture ) in the recent past. I started reading some blogs, sites and books about SOA to understand the basics and why we need to go towards SOA for today’s enterprises. I would like to share my ideas and knowledge I got in this process. Hope this would give you some pointers to start your journey of SOA.

What is Service Orientation :  Wiki tells us that, this is a paradigm to build software in form of services. We would take it further and can tell – “Think all logically divisible parts of your program as service”. Lets take a real time example for better understanding.

Case: Lets take a house which is having a 1 Hall, 1 Kitchen and 2 bed rooms (of-course couple of bath rooms as well). If you think in terms of services what are the services you could think of to form a house.

  • Electrical Wiring
  • Plumbing
  • Doors
  • Windows
  • Taps
  • Microwave
  • Fridge
  • Shower
  • Etc.

All these things together make a house. So, shall we think all these things as services?

Why not ?

If we have these many services, are we saying our house as SOA implementation ?

Now, what does SOA principles has to say about this –

Very similar to SOLID principles in Object Orientation, SOA has their own SOA principles. We have to look at them and figure out our model is matching with the SOA principles. You might think we already have these services as web services then SOA is the same. Are web service is the only way to achieve SOA ? that is a different question to answer but to be precise the current/contemporary way of implementing SOA is web services (May be in future we might have something different). Anyway, Lets get back to Principles of SOA.

Don’t get puzzled if they look very familiar 🙂

Loose Coupling: The services defined should maintain a relationship that minimizes dependencies, and only requires the awareness of each other.

Service Contract: All services should adhere to a service agreement. This could be a service description of a single or multiple related services. Services should do only whatever is mentioned in the contract.

Autonomy: Services should have a control over the logic they encapsulate. This means that each service should do the specific task and it should not do anything more than that.

Abstraction: Beyond what is described in the service contract, services hide the logic from outside world.

Reusability: Logic is divided into services with the intention of promoting reuse.

Composability: Collection of services can be coordinated and assembled to form composite services.

Statelessness: Services should minimize/zero retaining information specific to an activity / state.

Discoverability: Services are designed to be outwardly descriptive, so that they can be found and accessed via available discovery mechanisms.

Considering these principles, If you design any SOA system that would be considered as better architecture of your application. So, I feel these are the needs of current enterprise applications. And SOA can give a perfect solution if you are able to see the needs through your Service Orientation lenses.

Here are some Good Reads about SOA:

Book: Service-Oriented Architecture: Concepts, Technology, and Designjoi (Prentice Hall Service-Oriented Computing Series from Thomas Erl)

Articles:

SOA in a Nutshell by IBM Developer works

New to SOA and Web Services?

Another Good start would be – ServiceOrientation.com

Hope this read was helpful, Happy learning and reading !!!

What is Qos (Quality of Service) ?

What is Qos (Quality of Service) ?

The Quality of service or Quality attributes are most important for any Architecture, The Architect’s responsibility also consist of maintaining these services, well defined in any project and communicate the same to the development team. The QoS mostly consists of below services.

Other services like Performance, Interoperability, Usability, Maintainability etc are also very important. I am not discussing them here as I am trying to take the things very common and most important for any software application. As I am a JEE Architect, my examples and explanations might be of Java and related technologies.

Availability:

This is a very important service in the list and it means, the application you are working on should be available whenever the users are expected to use. This intern means it should be available 24 * 7, because of the distributed applications we have these days and users on almost all the countries and continents. To make this happen we might put the application in a clustered servers with a load balancing mechanism. This way we can make sure even if one server is down, the application requests can be served by other server in the cluster. Read more >>>

Manageability:

This is a very confusing concept as it is difficult to find difference between manageability and programmability. Although the lines are blurry between these two they are different and Manageability deals with the management of software. For Eg; How you manage your versions of the code? How you manage your build with any CI tools? How you configure your application itself? These kind of questions would come under Manageability. Read more >>>

Security:

Security is a key service any application should provide, the data of any application can’t be compromised, in some cases the code also. This is the thumb rule of any application. To keep the security there are some guidelines given by all programming languages which can be followed. I can give some examples for Java and .Net. The key features of the application like authorization, authentication, Encryption/Cryptography etc are the things should be taken care here. Read more >>>

Scalability:

Scaling any application is a challenge. We are in the cloud era and the hardware can be automatically scaled with the cloud providers. But still the software or the code we have written should be able to scale for the requirement of the future. This challenge is all about planning, usually we consider the application scope is very small and choose the technologies very much relevant for that scope, but after couple of years we start getting the response delays etc. Read more >>>

Reusability:

Reusability as a concept it is very easy to understand, all we have to do is “Re use” already existing things/ components / code / template etc. However the implementation of reusability in a real time project is not that easy. Very often we tend to copy paste the code instead of moving the code to another cohesive method, there could be many reasons to do that. At higher level abstraction like Component re use is much more difficult than a method or class. I feel identifying the use case itself is harder than implementing the reusability. Read more >>>

Portability:

Portability is often a thing which was not thought trough in the beginning of the development and be done ad hoc when it is needed. When we say portability, the application you develop should be portable to different environment all together, For eg; It could be moved from one OS to another OS or from regular environment to cloud. This is the part of portability.  Read more >>>

Other useful reference ->

Talk on Scalability, Performance and Reliability by Cameron Purdy

Portability and Reusability Chapter from Mcgraw-Hill.com

The Architecture based Design Method

Software architecture Definitions

Software architecture Definitions

Software Architecture has many different definitions, every expert of software industry has their own definitions 🙂

When you search for it your first result is most probably the Wikipedia which defines as below,

Wikipedia

The word software architecture intuitively denotes the high level structures of a software system. It can be defined as the set of structures needed to reason about the software system, which comprise the software elements, the relations between them, and the properties of both elements and relations.

Description: It talks about the high level plan / structure of a system / application, and architecture is the set of structures needed to build the software / application. It also says the relationships and properties of elements of the system is also important to consider.

IEEE-1471

An architecture is what is fundamental to a system — not necessarily everything about a system, but the essentials.

The dis-junction, concepts or properties, was chosen to support two different philosophies without prejudice. These philosophies are:

Architecture as Conception: an architecture is a concept of a system in one’s mind;
Architecture as Perception: an architecture is a perception of the properties of a system.
Under either philosophy, an architecture is abstract — not an artifact.

Description: IEEE completely took another dimension of Architecture, It says architecture is very abstract but it shows you two different perspectives of architecture. Finally it says Architecture is not an artifact, but still it has to be documented well. I will discuss how we can document the architecture in a different blog.

Microsoft – 

Software application architecture is the process of defining a structured solution that meets all of the technical and operational requirements, while optimizing common quality attributes such as performance, security, and manageability. It involves a series of decisions based on a wide range of factors, and each of these decisions can have considerable impact on the quality, performance, maintainability, and overall success of the application.

Description: If you re look at the above definition from Microsoft, it focuses on the process, and it says a series of decisions taken over time. So, it is more mature than the previous one as it talks about the quality attributes as well and their impact.If I interpret this definition, Architecture is not a one time thing, it is a continuous process of decisions which may impact your performance, security etc.

My Favorite definition of Architecture –

According to Ralph Johnson and Martin Fowler the Architecture Definition ( Who needs Architect )  – “In most successful software projects, the expert developers working on that project have a shared understanding of the system design. This shared understanding is called ‘architecture.’ This understanding includes how the system is divided into components and how the components interacted through interfaces. These components are usually composed of smaller components, but the architecture only includes the components and interfaces that are understood by all the developers. ”

 

Many other definitions of Software Architecture given by many industry experts consolidated by SEI ( Carnegie Mellon University).

Software Architects & Designers

Software Architects & Designers

Some days back when I was discussing something with my friend over a coffee we had this question. His idea goes like this – “All developers when they become seniors, they do design the system. If any developer with good  designing experience of some years, can become Architect.” I agree the fact, that you need a designing experience to become an Architect, however all designers may not be good fit for an Architect.

I would try to give my own definition of these two roles, let’s try to be on same page, then we can move on with the discussion point Architect Vs Designer.

Architect : He/ She is the one who defines the high level abstraction of the system/ software. The system/software may contain many different components inside. If it has many components then Architect’s job is to define the integration points, choose right technologies to different components, choose right tools & methodologies for these defined components. In some cases Architect even can influence the development process like introducing new step/ stage for code review and test with code static analysis tool before checking the code in to repository. He/ She is responsible for non-functional requirements like Scalable, Maintainable, Flexible, Available system.

Software Designer is not a very regular designation in software companies. So I would consider a Sr Developer / Technical Lead who is designing software for some years.

Designer : He / She define the low-level of the abstraction,each component should be designed by Designer to meet the functional requirements of that component by not compromising on Performance and Scalability of the system. Designing detailed interfaces and implementation of them.

I would like to map the things in a tabular format, for easier understanding.

Architect Designer
Vision Strategic (Long term – Alignment to Business) Tactical (Short term – Integration between modules /components)
Abstraction High Level Low level
Defines Skeleton of the System Fill the Skeleton with Designing the details
High level components Design each Component
Involved When ?  “What” Phase of the system “How” Phase of the system
Focus Area ? Non Functional requirements (Scalability,Availability,Flexibility etc) Focus – Functional requirements
Suggest Frameworks, Methodologies, Integrations, Tools, Technologies, Patterns etc Best Practices, Applying Design Patterns, Design Considerations
Create Component Diagram, Interaction overview, Deployment, Use case, Class, Package(optional) Class, Package, Object, Activity, Sequence
Document Architecture Overview, Integrations, Design Decisions Design Decisions, Best Practices, How to ..s ?, CODE

Finally a pictorial view

Architect_Vs_Designer

I hope this is useful for the people who are trying to understand these roles. Thanks

Useful references :

Software Architecture defined by Carnegie Mellon University

Learn UML Diagrams and their Importance

StackOverflow Architecture Vs Design Discussion