WHY DOCKER ?

Why Docker ?

COMMUNITY SUPPORT

DOCKER on Single Host

DOCKER-DEVELOPMENT-ENVIRONMENT

 

DOCKER PLATFORM & Related Tools

DOCKER-FLOW

Vagrant Commands

What is Vagrant ?

• Vagrant is a tool that uses Oracle's VirtualBox to dynamically build configurable, lightweight, and portable virtual machines. 
• Vagrant supports the use of either Puppet or Chef for managing the configuration.

vagrant -v 

vagrant up, halt 
- up is used to create & configure your guest environment/machines based on  your  vagrantfile.
- halt bring down the environment Vagrant is managing.

vagrant status
- status of the Vagrant managed machines.

vagrant reload
-  apply Vagrant configuration changes (like port forwarding) without rebuilding the VM.

vagrant suspend, resume
- saves the state of the current VM.- resume will load up the suspended VM.

vagrant init, destroy 
- init initializes a project to use Vagrant
- Beware. This command will bring down the environment if running and then destroys
all of the resources that were created along with the initial creation.

vagrant push
- Vagrant can be configured to deploy code !

vagrant ssh 
- SSH into your Vagrant running machines.

vagrant login 
- log into Vagrant cloud (Atlas).

vagrant share 
- Do form folder with vagrantfile

vagrant global-status
- List all VMs status anywhere on the system.

vagrant gem
- install Vagrant plugins via RubyGems

vagrant box (add, list, remove) 
- vagrant box add, allows you to install a box (or VM) to the local machine
-  vagrant box remove, a box from the local machine
-  vagrant box list, the locally installed Vagrant boxes

vagrant -help 
- That will provide man pages for a Vagrant command.

Configuration Management Tool : Puppet,  Chef, Ansible, Salt, Docker
vagrant provision, reload --provision 
- provisioning runs on up only

Create own boxes with vagrant or packer
vagrant package
- To create a distribution of the vm you have running.

Vagrant plugin list : click here

vagrant plugin install vagrant-berkshelf
vagrant plugin install vagrant-hostmanager
vagrant plugin install vagrant-omnibus

Vagrant Boxes List : click here

Vagrant Example :

vagrant box add precise32 http://files.vagrantup.com/precise32.box

vagrant init precise32

vagrant up

vagrant ssh

vagrant reload

vagrant provision

Microservices Architecture – Spring Boot, Spring Cloud and Netflix OSS Infrastructure

What is "Microservices"?

• A suite of small services that use lightweight mechanism like REST to communicate with each other. 
• These services are built around business capabilities and independently deployable by fully automated deployment machinery.

Why Micro Services Architecture?

We chose micro services architecture to write each functionality as a separate service for core and API functionality and it helps us to achieve the continuous delivery and integration.

Frameworks

There are couple of frameworks available in different software ecosystems that make it easy to create distributed applications using microservices architecture.

1. Java – Spring Cloud using Netflix OSS
2. Node.js – Seneca

• The reference architecture developed by us builds on the Spring Cloud ecosystem.
• There are number of components available within the Spring Cloud and Netflix OSS ecosystem that solve common problems for distributed applications
  (e.g. configuration management, service discovery, circuit breakers, intelligent routing etc).

Patterns in Micro Services Architecture :

• API Gateway
• Service Registry
• Service Discovery

Patterns in Micro services Architecture

API Gateway	Choose to build the application as a set of micro-services. Decide how the application client’s will interact with the micro services With a monolithic application there is just one set of (typically replicated, load-balanced) endpoints. In a micro services, architecture, however each micro services exposes a set of what are typically fine-grained endpoints.
Service Registry	Service registry helps to determine the location of service instances to send request to the corresponding services. Here, we have used the Netflix Eureka to register a service that are available to be registered in service registry server and it can be identified through the router.
Service Discovery	In a monalithic application, services invoke one another through language-level method or procedure calls. But, in a modern icro services based application typically runs in a virtualized environments where the number of instances of service and their locations changes dynamically Each service can be identified using router that are registered with service registry server

Microservices Architecture using Netflix Components :
We have used the Netflix components to accomplish the above microservices architecture patterns.

Operations Component	Spring Cloud, Netflix OSS
Service Discovery Server	Netflix Eureka
Edge Server	Netflix Zuul
Central Configuration Server	Spring Cloud Config Server
Dynamic Routing and Load Balancer	Netflix Ribbon
OAuth 2.0 protected API’s	Spring Cloud + Spring Security OAuth2
Circuit Breaker	Netflix Hystrix
Monitoring	Netflix Hystrix Dashboard and Turbine
Centralized Log Analysis	ELK (Elasticsearch,Logstash,Kibana)

Major Components of Netflix :

Netflix Eureka – Service Discovery Server

Netflix Eureka allows micro services to register themselves at runtime as they appear in the system landscape.

Netflix Ribbon – Dynamic Routing & Load Balancer

Netflix Ribbon can be used by service consumers to look up services at runtime. Ribbon uses the information available in Eureka to locate appropriate service instances. If more than one instance is found, Ribbon will apply load balancing to spread the requests over the available instances. Ribbon does not run as a separate service but instead as an embedded component in each service consumer.

Netflix Zuul – Edge Server & API gatewayer

Zuul is (of course) our gatekeeper to the outside world, not allowing any unauthorized external requests pass through. Zulu also provides a well-known entry point to the micro services in the system landscape. Using dynamically allocated ports is convenient to avoid port conflicts and to minimize administration but it makes it of course harder for any given service consumer. Zuul uses Ribbon to look up available services and routes the external request to an appropriate service instance.

Spring Boot & Spring Cloud Netflix OSS – Micro Service Architecture

Micro Services with Spring Boot :

Spring Boot is a brand new framework from the team at Pivotal, designed to simplify the bootstrapping and development of a new spring application. The framework takes an opinionated approach to configuration, freeing developers from the need to define boilerplate configuration.

Spring Cloud Netflix :

Spring cloud Netflix provides Netflix OSS integrations for spring boot apps through auto configuration and binding to the spring environment and other spring programming models. With a few simple annotations we can quickly enable and configure common patterns inside application and to build large distributed systems with Netflix components. There are lot of features available with spring cloud Netflix. Here, we have listed some of the common features we have implemented with micro services with spring boot and Netflix,

Service Discovery	Eureka instances can be registered and clients can discover the instances using spring managed beans.
Service Creation	An embedded Eureka server can be created with declarative Java Configuration
External Configuration	A bridge from the Spring Environment(enables native configuration of Netflix components using Spring Boot conventions)
Router and Filter	Automatic registration of Zuul filters, and a simple convention over configuration approach to reverse proxy creation

You can view on PDF, Please click here: www.optisolbusiness.com/Micro-Services-Architecture-Spring-Boot-and-Netflix-Infrastructure.pdf

• Anil Allewar
• Martin Fowler

Spring Cloud and Netflix OSS

How do services find each other?
How do I configure many instances of each service?
How do I see what’s going on with my services?

Some answers using Spring Cloud and Netflix OSS to create microservices that are robust, discoverable, scalable and configurable.

• Spring Cloud Config Server (distributed configuration)
• Eureka (service registration and discovery)
• Hystrix (circuit breaker/fault tolerance library)
• Hystrix Dashboard (service health dashboard)
• Ribbon (client side load balancing, including RestTemplate integration)
• Feign (easy rest clients)
• Zuul (routing)
• Spring Cloud Bus (distributed Spring Boot actuator)
• Spring Cloud Security
• Reactive programming patterns 

Some answers using Spring Cloud and Netflix OSS to create microservices that are robust, discoverable, scalable and configurable

Microservices Design Pattern

The patterns

• Monolithic architecture
• Microservices architecture
• API gateway
• Client-side discovery
• Server-side discovery
• Service registry
• Self registration
• 3rd party registration
• Multiple service instances per host
• Single service instance per host
• Service instance per VM
• Service instance per Container
• Database per Service
• Microservice chassis

Microservice database challenges

A few different ways to keep a service’s persistent data private. For example,  if you are using a relational database then the options are:

1. Private-tables-per-service : each service owns a set of tables that must only be accessed by that service
2. Schema-per-service : each service has a database schema that’s private to that service
3. Database-server-per-service : each service has it’s own database server.

There are some downsides to keeping a service’s persistent data private.

• It might also make sense to have a polyglot persistence architecture. For each service you choose the type of database that is best suited to that service’s requirements. For example, a service that does text searches could use ElasticSearch. A service that manipulates a social graph could use Neo4j. It might not make sense to use a relational database for every service.
  
• Most notably, it can be challenging to implement business transactions that update data owned by multiple services. Rather than using distributed transaction, you typically must use an eventually consistent, event-driven approach to maintain database consistency.
• Another problem, is that it is difficult to implement some queries because you can’t do database joins across the data owned by multiple services. Sometimes, you can join the data within a service. In other situations, you will need to use Command Query Responsibility Segregation (CQRS) and maintain denormalizes views.
• Another challenge is that  services sometimes need to share data. For example, let’s imagine that several services need access to user profile data. One option is to encapsulate the user profile data with a service, that’s then called by other services. Another option is to use an event-driven mechanism to replicate data to each service that needs it.

 

MICROSERVICES DESIGN-PATTERN

A pattern language for microservices

Challenges of Monolithic Architecture:

• Inflexible - Monolithic applications cannot be built using different technologies.
• Unreliable - If even one feature of the system does not work, then the entire system does not work.
• Unscalable - Applications cannot be scaled easily since each time the application needs to be updated, the complete system has to be rebuilt.
• Blocks Continuous Development - Many features of an application cannot be built and deployed at the same time.
• Slow Development - Development in monolithic applications takes a lot of time to be built since each and every feature has to be built one after the other.
• Not Fit for Complex Applications - Features of complex applications have tightly coupled dependencies.

The above challenges were the main reasons that led to the evolution of microservices.
Microservices, aka Microservice Architecture, is an architectural style that structures an application as a collection of small autonomous services, modeled around a business domain.

Microservices Representation.

In microservice architecture, each service is self-contained and implements a single business capability.
Consider an e-commerce application as a use case to understand the difference between both of them.

Differences Between Monolithic Architecture and Microservices.

The main difference we observe in the above diagram is that all the features were initially under a single instance sharing a single database, but then, with microservices, each feature was allotted a different microservice, handling their own data, and performing different functionalities.

• Different clients from different devices try to use different services like search, build, configure, and other management capabilities.
• All the services are separated based on their domains and functionalities and are further allotted to individual microservices.
• These microservices have their own load balancer and execution environment to execute their functionalities, and at the same time, captures data in their own databases.
• All the microservices communicate with each other through a stateless server which is either REST or a Message Bus.
• Microservices know their path of communication with the help of Service Discovery and perform operational capabilities such as automation and monitoring.
• All the functionalities performed by microservices are communicated to clients via an API Gateway.
• All the internal points are connected from the API Gateway so anybody who connects to the API Gateway is automatically connected to the complete system.

Now, let us learn more about microservices by looking at its features.

Features of Microservices.

• Decoupling - Services within a system are largely decoupled, so the application as a whole can be easily built, altered, and scaled.
• Componentization - Microservices are treated as independent components that can be easily replaced and upgraded.
• Business Capabilities - Microservices are very simple and focus on a single capability.
• Autonomy - Developers and teams can work independently of each other, thus increasing speed.
• Continous Delivery - Allows frequent releases of software through systematic automation of software creation, testing, and approval.
• Responsibility - Microservices do not focus on applications as projects. Instead, they treat applications as products for which they are responsible.
• Decentralized Governance - The focus is on using the right tool for the right job. That means there is no standardized pattern or any technology pattern. Developers have the freedom to choose the best useful tools to solve their problems.
• Agility - Microservices support agile development. Any new feature can be quickly developed and discarded again.

Advantages of Microservices.

• Independent Development - All microservices can be easily developed based on their individual functionality.
• Independent Deployment - Based on their services, they can be individually deployed in any application.
• Fault Isolation - Even if one service of the application does not work, the system still continues to function.
• Mixed Technology Stack - Different languages and technologies can be used to build different services of the same application.
• Granular Scaling - Individual components can scale as per need, there is no need to scale all components together.

The following are the best practices to design microservices:

Best practices to design microservices.

Now, let us look at a use-case to get a better understanding of microservices.
Let's take a classic use case of a shopping cart application. When you open a shopping cart application, all you see is just a website. But, behind the scenes, the shopping cart application has a service for accepting payments, a service for customer services and so on.
Assume that developers of this application have created it in a monolithic framework. Refer to the diagram below:

Monolithic Framework of a Shopping Cart Application.

So, all the features are put together in a single code base and are under a single underlying database.
Now, let's suppose that there is a new brand coming up in the market and developers want to put all the details of the upcoming brand in this application. Then, they not only have to rework the service for new labels, but they also have to reframe the complete system and deploy it accordingly.
To avoid such challenges developers of this application decided to shift their application from a monolithic architecture to microservices. Refer to the diagram below to understand the microservices architecture of shopping cart application:

Microservice Architecture of a Shopping Cart Application.

This means that developers don't create a web microservice, a logic microservice, or a database microservice. Instead, they create separate microservices for search, recommendations, customer services and so on.