Spring Boot

• What is Spring Boot

1. Radically faster getting started experience
2. "Opinionated" approach to configuration / defaults

       - Intelligent defaults
       - Gets out of the way quickly


    3. What does it involve?
       - Easier dependency management
       - Automatic configuration / reasonable defaults
       - Different build / deployment options.

• What Spring Boot is NOT

1. Plugins for IDEs

       - Use Boot with any IDE(or none at all)

    2. Code generation

___________________________________________________________________________
Demonstration - Spring Boot

Create a new, bare-bones Spring application

eclipse
Help -> eclipse marketplace -> spring ide search -> Spring Tools 4 (aka Spring Tool suite 4) 4.6.0. RELEASE -> install -> restart

Project Explorer right click -> new -> other -> Spring Boot -> Spring Starter Project

name: microserviceBoot, java Version 8 -> next -> next


"Tomcat version 8.0 only supports J2EE 1.2, 1.3, 1.4, and Java EE 5 and 6 WEb modules"
project foloer .settings>org.eclipse.wst.common.project.facet.core.xm

          

 

 

 

 

 

  4.0

"/>  => 2.5

 

____________________________________________________________________________

• Spring Boot - What just Happened?

1. Boilerplate project structure created

      - Mostly folder structure

      - "Application" class + test

      - Maven POM (or Gradle if desired)

    2. Dependency Management

• Running Spring Boot-What Just Happened?

1. SpringApplication

        - Created Spring Application Context

    2. @SpringBootApplication

       - Combination of @Configuration

           i) Marks a configuration file

           ii) Java equivalent of file

       

       - ...And @ComponentScan

           i) Looks for @Componenrts (none at the moment)

       - ...And @EnableAutoConfiguration

           i) Master runtime switch for Spring Boot

           ii) Examines ApplicationContext & classpath

           iii) Creates missing beans based on intelligent defaults

____________________________________________________________________________________
Demonstration - Adding Web Capability

- Adding spring-boot-starter-web dependency
- Adding HelloController

pom.xml
spring-boot-starter => spring-boot-starter-web

com.example.demo package
create classes => WhateverIWant

package com.example.demo;

import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.ResponseBody;

@Controller
public class WhateverIWant {

@RequestMapping("/hi")
public @ResponseBody String hiThere()
{
return "hello world!";
}

}

Run As -> Spring Boot App

____________________________________________________________________________________

• Adding Web - What Just Happened?

1. spring-boot-starter-web Dependency

       - Adds spring-web, spring-mvc jars

       - Adds embedded Tomcat jars

    2. When application starts...

       - Your beans are created

       - @EnableAutoConfiguration looks for  'missing' beans

          i) Based on your beans + classpath

          ii) Notices @Controller / Spring MVC jars

     

       - Automatically creates MVC beans

          i) DispatcherServlet, HandlerMappings, Adapters, ViewResolvers

       - Launches embedded Tomcat instance.

• But wait, I want a WAR...

1. To Convert from JAR to WAR:

      - Change POM packaging

      - Extend SpringBootServletInitializer

 

   2. Deploy to app server

      - URL becomes http://localhost:8080//

_______________________________________________________________________________________

Demonstration - WAR Deployment

-WAR Packaging
-SpringBootServletInitializer


pom.xml

element 
 jar -> war
 or add war


MicroservicesBootApplication.java

package com.example.demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.builder.SpringApplicationBuilder;
import org.springframework.boot.web.servlet.support.SpringBootServletInitializer;

@SpringBootApplication
public class MicroservicesBootApplication extends SpringBootServletInitializer{


/**
* Used when run as a JAR
* @param args
*/
public static void main(String[] args) {
SpringApplication.run(MicroservicesBootApplication.class, args);
}

/**
* Used when run as a WAR
*/
@Override
protected SpringApplicationBuilder configure(SpringApplicationBuilder builder) {

return builder.sources(MicroservicesBootApplication.class);
}



}

________________________________________________________________________________________

• What about Web Pages?

1. Spring MVC supports a wide range of view options
2. Easy to use JSP, Freemarker, Velocity, Thymeleaf
3. Boot automatically establishes defaults

      - InternalResourceViewResolver for JSPs

      - ThymeleafViewResolver

         i) If Thymeleaf is on the classpath

    

     4. spring-boot-starter-thymeleaf

___________________________________________________________________________________________

Demonstration - Thymeleaf web pages

- spring-boot-starter-thymeleaf
- /templates folder
- Controller adjustments
- Web page


pom.xml

add


org.springframework.boot
spring-boot-starter-thymeleaf

search google  => spring boot reference

spring Boot Reference Guide

spring-boot-starter-thymeleaf 

resource add Folder
name: templates

add hello.html




Hello name-goes-heae from a Thymeleaf page





WhateverIWant.java

@RequestMapping("/hi/{name}")
public  String hiThere(Map model, @PathVariable String name)
{
model.put("name", name);
return "hello";
}

____________________________________________________________________________________________

• What Just Happended?

1. spring-boot-starter-theymeleaf

       - Brought in required jars
       - Automatically configured ThymeleafViewResolver

    2. Controller returned a 'logical view name'
   
    3. View Resolver found a matching template

    4. Render

• But wait, I want JSPs...

1. Thymeleaf and other templating approaches are way too advanced for my organization!

       - Besides, we have lots of existing JSPs

    2. No Problem!

  

    3. Just as easy to use JSPs!

       - Place JSPs in desired web-relative location

       - Set spring.mvc,view.prefix / spring.mvc.view.suffix as needed. 
       - (remove thymeleaf starter pom)

______________________________________________________________________________________________

Demonstration - JSP Web Pages

- Place JSP in desired folder
- Set spring.mvc.view.prefix / spring.mvc.view.suffix
- Exclude spring-boot-starter-tomcat

Project Explorer

src -> main -> webapp -> create folder -> WEB-INF -> views -> hello.jsp





Hello ${name} from a JSP page

src/main/resources/appcliaction.properties


spring.mvc.view.prefix=/WEB-INF/views/
spring.mvc.view.suffix=.jsp

_______________________________________________________________________________________________

• What Just Happened?

1. No ThymeleafViewRresolver configured
2. Controller returned a 'logical view name'
3. InternalResourceViewResolver forwarded to JSP
4. Render

• Spring & REST

1. REST capability is built in to Spring MVC

      - Simply use domain objects as parameters / return values.
      - Mark with @RequestBody / @ResponseBody
      - Spring MVC automatically handles XML/JSON conversion
           *Based on converters available in classpath.


___________________________________________________________________________________________

DemonStration - REST Controllers in Spring MVC
 
- Additional domain objects
- Automatic HTTP Message Conversion


package com.example.demo.domain;

public class Player {

String name;
String position;



public Player() {
super();

}


public Player(String name, String position) {
this();
this.name = name;
this.position = position;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public String getPosition() {
return position;
}
public void setPosition(String position) {
this.position = position;
}



}

package com.example.demo.domain;

import java.util.Set;

public class Team {

String name;

String location;

String mascotte;

Set players; 

public Team() {

super();

}

public Team(String location, String name, Set players) {

this();

this.location = location;

this.name = name;

this.players = players;

}

public String getName() {

return name;

}

public void setName(String name) {

this.name = name;

}

public String getLocation() {

return location;

}

public void setLocation(String location) {

this.location = location;

}

public String getMascotte() {

return mascotte;

}

public void setMascotte(String mascotte) {

this.mascotte = mascotte;

}

public Set getPlayers() {

return players;

}

public void setPlayers(Set players) {

this.players = players;

}

}

package com.example.demo;

import java.util.HashSet;

import java.util.Map;

import java.util.Set;

import javax.annotation.PostConstruct;

import org.springframework.stereotype.Controller;

import org.springframework.web.bind.annotation.PathVariable;

import org.springframework.web.bind.annotation.RequestMapping;

import org.springframework.web.bind.annotation.ResponseBody;

import com.example.demo.domain.Player;

import com.example.demo.domain.Team;

@Controller

public class WhateverIWant {

private Team team;

@PostConstruct

public void init()

{

Set players = new HashSet<>();

players.add(new Player("Charlien Brown", "pitcher"));

players.add(new Player("Snoopy", "shortstop"));

team = new Team("California", "Peanuts", players);

}

@RequestMapping("/hi")

public @ResponseBody Team hiThere()

{

return team;

}

}

____________________________________________________________________________________________

What Just Happened?

1. Controller returned a domain object
   - Not a logical view name (page)

2. Spring MVC noticed @ResponseBody
   - Or @RestController

3. Invoked correct HttpMessageConverter
  - Based on
     * Requested format
     * JARS on classpath


What if I want XML?

1. No Problem!

2. Annotate domain classes with JAXB annotations
  - JAXB already part of java SE

3. When App Starts
   - Spring creates HttpMessageConverter fo JAXB
      * Based on classpath contents

4. XML or JSON returned
   - based on requested format



@XmlRootElement   => xml out

Accept: application/xml

Accept: application/json


Adding JPA Capability

1. Adding the spring-boot-starter-data-jps Dependency
   - Adds Spring JDBC/ Transaction Management
   - Adds Spring ORM
   - Adds Hibernate / entity manager
   - Adds Spring Data JPA subproject
     * (explained later)


2. Does NOT add a Database Driver
   - Add one manually (HSQL)






Spring Data JPA

1. Typical web application architecture

2. REST Controllers provide CRUD interface to clients

3. DAO provide CRUD interface to DB




Spring Data - Instant Repositories

1. Spring Data provides dynamic repositories

2. You provide the interface, Spring Data dynamically implements.
- JPA, MongoDB, GemFire, etc.

3. Service Layer / Controllers have almost no logic.


_____________________________________________________________________________________________

Demonstraion - Adding Spring Data JPA

- spring-boot-starter-data-jpa
- org.hsqldb / hsqldb
- Annotate domain objects with JPA
- Extend CrudRepository


pom.xml


org.springframework.boot
spring-boot-starter-data-jpa

org.hsqldb
hsqldb



package com.example.demo.domain;

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;

@Entity
public class Player {

@Id @GeneratedValue
Long id;
String name;
String position;



public Player() {
super();

}


public Player(String name, String position) {
this();
this.name = name;
this.position = position;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public String getPosition() {
return position;
}
public void setPosition(String position) {
this.position = position;
}



}

package com.example.demo.domain;

import java.util.Set;

import javax.persistence.CascadeType;

import javax.persistence.Entity;

import javax.persistence.GeneratedValue;

import javax.persistence.Id;

import javax.persistence.JoinColumn;

import javax.persistence.OneToMany;

import javax.xml.bind.annotation.XmlRootElement;

@XmlRootElement

@Entity

public class Team {

@Id @GeneratedValue

Long id;

String name;

String location;

String mascotte;

@OneToMany(cascade=CascadeType.ALL) 

@JoinColumn(name="teamId")

Set players; 

public Team() {

super();

}

public Team(String location, String name, Set players) {

this();

this.location = location;

this.name = name;

this.players = players;

}

public String getName() {

return name;

}

public void setName(String name) {

this.name = name;

}

public String getLocation() {

return location;

}

public void setLocation(String location) {

this.location = location;

}

public String getMascotte() {

return mascotte;

}

public void setMascotte(String mascotte) {

this.mascotte = mascotte;

}

public Set getPlayers() {

return players;

}

public void setPlayers(Set players) {

this.players = players;

}

}

package com.example.demo.dao;

import java.util.List;

import org.springframework.data.repository.CrudRepository;

import com.example.demo.domain.Team;

public interface TeamDao extends CrudRepository {

List findAll();

Team findByName(String name);

}

package com.example.demo;

import java.util.HashSet;

import java.util.Set;

import javax.annotation.PostConstruct;

import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.boot.SpringApplication;

import org.springframework.boot.autoconfigure.SpringBootApplication;

import org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration;

import org.springframework.boot.builder.SpringApplicationBuilder;

import org.springframework.boot.web.servlet.support.SpringBootServletInitializer;

import com.example.demo.dao.TeamDao;

import com.example.demo.domain.Player;

import com.example.demo.domain.Team;

@SpringBootApplication

public class MicroservicesBootApplication extends SpringBootServletInitializer{

/**

* Used when run as a JAR

* @param args

*/

public static void main(String[] args) {

SpringApplication.run(MicroservicesBootApplication.class, args);

}

/**

* Used when run as a WAR

*/

@Override

protected SpringApplicationBuilder configure(SpringApplicationBuilder builder) {

return builder.sources(MicroservicesBootApplication.class);

}

@PostConstruct

public void init()

{

Set players = new HashSet<>();

players.add(new Player("Charlien Brown", "pitcher"));

players.add(new Player("Snoopy", "shortstop"));

Team team = new Team("California", "Peanuts", players);

teamDao.save(team);

}

@Autowired TeamDao teamDao;

}

package com.example.demo;

import java.util.HashSet;

import java.util.Map;

import java.util.Set;

import javax.annotation.PostConstruct;

import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.stereotype.Controller;

import org.springframework.web.bind.annotation.PathVariable;

import org.springframework.web.bind.annotation.RequestMapping;

import org.springframework.web.bind.annotation.ResponseBody;

import org.springframework.web.bind.annotation.RestController;

import com.example.demo.dao.TeamDao;

import com.example.demo.domain.Player;

import com.example.demo.domain.Team;

@RestController

public class WhateverIWant {

@Autowired TeamDao teamDao;

@RequestMapping("/teams/{name}")

public  Team hiThere(@PathVariable String name)

{

return teamDao.findByName(name);

}

}

_____________________________________________________________________________________________

Adding Spring Data JPA - What Just Happened?

1. What I did:
  - Added dependencies for spring-boot-starter-data-jpa and hsqldb
  - Annotated Domain objects with plain JPA annotations
  - Added an interface for Spring Data JPA
  - Dependency injected info controller


2. When application starts...
   - Spring Data dynamically implements repositories
     * find*(), delete(), save() methods implemented.
   - DataSource, Transaction Management, all handled.


Spring Data - REST

1. Often, applicatons simply expose DAO methods as REST resources

2. String Data REST handles this automatically...

Adding Spring Data REST

1. Plugs into dynamic repositories

2. Generates RRESTful interface
 - GET, PUT, POST, DELETE

3. Code needed only to override defaults.


__________________________________________________________________________________________

__________________________________________________________________________________________

Adding Spring Data REST - What Just Happened?

1. when applicaton starts...
   - @RestResource annotations interpreted
   - @Controllers beans created
   - @RequestMappings created


Adding HATEOAS

1. Spring Data Rest simply returns RESTful resources
- Conversion handled by Jackson, or JAXB

2. Underlying Data Relationships used to build Links
- If matching repositories exist

3. Consider the Team -> Player relationship

4. Player Repository needed to force link creation


__________________________________________________________________________________________

Demonstration - Adding HATEOAS Links
-  Creating a Player DAO


package com.example.demo.domain;

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;

@Entity
public class Player {

@Id @GeneratedValue
Long id;
String name;
String position;



public Player() {
super();

}


public Player(String name, String position) {
this();
this.name = name;
this.position = position;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public String getPosition() {
return position;
}
public void setPosition(String position) {
this.position = position;
}



}

_______________________________________________________________________________________________

HATEOAS - What Just Happened?

1. Spring Data REST noticed two repositories
  - The relationship between entities is know via JPA annotations.

2. Spring automatically represents the children as links
  - @RestResource determines names of links


Summary
1. Spring Boot makes it easy to start projects
  - And easy to add featrure sets to projects
  - Opinionated apporach
  - Run as JAR or WAR
  - Web Applications (JSP, Thymeleaf, others)

2. REST
  - Automatic resource conversion

3. Spring Data JPA
  - Automatic repository implementation
 
4. Spring Data REST
  - Automatic REST controllers

What are Microservices

• What are Microservices

1. Presently a lot of hype!

1. Best described as:
2. An architectural style
3. An alternative to more traditional 'monolithic' applications
4. Decomposition of single system into a suite of small services, each running as independent proceses and intercommunicating via open protocols

       - With all the benefits / risks this implies.

• Definitions from the Experts

1. 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.                 

      - Martin Fowler    

    

     2. Fine-grained SOA

      - Adrian Cockcroft - Netflix

• Microservices - Working Definition:

1. Composing a single application using a suite of small services

       - (rather than a single, monolithic application)

    2. ... each running as independent processes

       - (not merely modules / components within a single executable)

    3. ... intercommunicationg via open protocols

       - ( Like HTTP/REST, or messaging)

    4.  Separately written, deployed, scaled and maintained

       - ( potentially in different languages)

    5.  Services encapsulate business capability

      - ( rather than language constructs (classes, packages) as primary way to encapsulate.

    6. Services encapsulate business capability

      - ( rather than language constructs (classes, packages) as primary way to encapsulate.

    7. Services are independently replaceable and upgradable

• Microservices are not:

    1. The same as SOA

       - SOA is about integrating various enterprise applications.

         Microservices are mainly about decomposing single applications

    2. A silber bullet

       - The microservices approach involves drawbacks and risks

    3. New! You may be using microservices now and not konw it!

• Current Trends

    1. Twitter moved from Ruby/Rails monolith to Micorservices.

    2. Facebook moved from PHP monolith to Microservices.

    3. Netflix moved from Java monolith to Microservices.

• Microservices Example

    1. Consider a monolithic shopping cart application:

      - Web / mobile interfaces

      - Functions for:

          i) searching for products

          ii) Product catalog

          iii) Inventory management

          iv) Shopping cart

          v) Checkout

          vi) Fufillment

       - How would this look with microservices?

• Monlolithic Application Example

    1. Monolithic shopping cart application:

    2. Understanding the Monolithic Architecture

 

   3. New types of client applications

   4. New type of persistence / services

• Monolithic Challenges

    1. Single Codebase, Deployment, Versioning, Team Size
 

           

     2. Using Teams / Language Constructs

• Understanding the monolithic implementation

       1. Single application executable
          - Easy to comprehend, but not to digest.
          - Must be written in a single language.
       2. Modularity based on Program Language
          - Using the constructs available in that language (packages, classes, functions,                namespaces, frameworks)
         - Various storage / service technologies used
           => REBMS, Messaging, eMail, etc.

• Monolithic Advantages

1. Easy to comprehend(but not digest)
2. Easy to test as a single unit (up to a size limit)
3. Easy to deploy as a single unit.
4. Easy to manage (up to a size limit)
5. Easy to manage changes (up to a point)
6. Easy to scale (when care is taken)
7. Complexity managed by language constructs.

• Monolithic Drawbacks

   1. Language / Framework Lock
      - Entire app written with single technology stack. Cannot experiment / take                    advantage of emerging technologies
   2. Digestion
      - Single developer cannot digest a large codebase
      - Single team cannot manage a single large application   
        => Amazon's "2 Pizza" rule
   3. Deployment as single unit
     - Cannot independently deploy single change to single component.
     - Changes are "held-hostage" by other changes     

• Enter Microservices architecture

• Compoentization via Services

1. NOT language constructs.
2. Where services are smaill, independently deployabl applications
3. Forces the design of clear interfaces
4. Changes scoped to their affected service

• Microserices: Composed using suite of small services

1. Services are small, independently deployable applications

      - Not a single codebase
      - Not (necessarily) a single language / framework
      - Modularization not based on language / framework constructs

• Microservices: Communication based on lightweight protocols

1. HTTP, TCP, UDP, Messaging, etc.

      - Payloads: JSON, BSON, XML, Protocol Buffers, etc.
    2. Forces the design of clear interfaces
    3. Netflix's Cloud Native Architecture - Communicate via APIs
      - NOT Common Database

• Microservices: Services encapsulate business capabilities

1. Not based on technology stack
2. Vertical slices by business function (i.e. cart, catalog, checkout)
3. ...Though technology chunk also practical (email service)
4. Suitable for cross-functional teams

• Micoroservices: Services easily managed

1. Easy to comprehend, alter, test, version, deploy, manage, overhaul, replace

       - By small, cross-functional teams (or even individuals)

• Decentralized Governance

1. Use the right tool ( language, framework) for the job.
2. Services evolve at different speeds, deployed and managed according to different needs.
3. Make services be "Tolerant Readers"
4. Consumer-0Driven Contracts
5. Antithesis of ESB

      - Services are not Orchestrated, but Choreographed

• Polyglot Persistence

1. Freedom to use the best technology for the job

      - Don't assume single RDBMS is always best
      - Very controversial! Many DBAs will not like this!
         i) No pan-enterprise data model!
         ii) No transactions!

• Microservice Advantages

1. Easy to digest each service (difficult to comprehend whole)
2. VERY easy to test, deploy, manage, version, and scale single services
3. Change cycle decoupled
4. Easier to scale staff
5. No Language / Framework lock

• Challenges with Microservices

1. Complexity has moved out of the application, but into the operations layer

       - Fallacies of Distributed Computing

    2. Services may be unavailable
       - Never needed to worry about this in a monolith!
       - Design for failure, circuit breakers
        i) "Everything fails all the time" - Werner Vogels, CTO Amazon
       - Much more monitoring needed
 
     3. Remote calls more expensive than in-process calls

     4. Transactions: Must rely on eventual consistency over ACID

     5. Features span multiple services

     6. Change management becomes a different challenge
        - Need to consider the interaction of services
        - Dependency management / versions
 
      7. Refactoring Module Boundaries

• Fallacies of Distributed Computing

1. The network is reliable.
2. Latency is zero.
3. Bandwidth is infinite.
4. The network is secure.
5. Topology doesn't change.
6. Therre is noen administrator.
7. Transport cost is zero.
8. The network is homogeneous.

• How Do You Break a Monolith into Microservices?

1. Primary consideration: business functionality:

       - Noun-based (catalog, cart, customer)
       - Verb-based (search, checkout, shipping)
       - Single Responsibility Principle
         => http://programmer.97things.oreilly.com/wiki/index.php/The_Single_Responsibility_Principle
       - Bounded Context
         => http://martinfowler.com/kliki/BoundedContext.html

• How Micro is Micro?

1. Size  is not the compelling factor

      - Smaill enough for an individual developer to digest
      - Small enough to be built and managed by small team
        i) Amazon's two pizza raule
      - Documentation small enough to read and understand
        i) Social Security Act of 1935 - 63 pages
        ii) Affordable Care Act of 2010 - 906 pages

       - Dozens of secrets, not hundreds.
       - Predictable. Easy to experiment with

• Differences with SOA

1. SOA addresses integration between systems.

       - Microservices address individual applications
    2. SOA relies on orchestration.
       - Microservices rely on choreography

    3. SOA relies on smart integration technology, dumb services
       - Microservices rely on smart services, dum integration technology
       - Consider: Linux commands, pipes and filters

 

• Are Monoliths Always Bad?

1. Consider etsy.com

       - As of Rebruary 2013: 1.49 billion page views, 4,215,169 items sold, $94.7 million             of goods sold, 22+ million members
       - 150 developers deploy single WAR 60 tiems a day
       - Practices: Cl; push button deployment; good monitoring; developers deploy to             the site on the first day; VMs per developer; GitHub; Chef; IRC to controll                     releases; dashboards; no source control branches.

docker run -d --name kuard --publish 8080:8080 gcr.io/kuar-demo/kuard-amd64:1

curl http://localhost:800

docker stop kuard
docker rm kuard


docker run -d --name kuard --publish 8080:8080 --memory 200m --memory-swap 1G gcr.io/kuar-demo/kuard-amd64:1


docker run -d --name kuard --publish 8080:8080 --memory 200m --memory-swap 1G --cpu-shares 1024 gcr.io/kuar-demo/kuard-amd64:1


docker rmi
docker rmi

virtualbox uninstall

System Preferences -> security & privacy  -> Oracle America, inc allow

virtualbox install

minikube start

minikube start --kubernetes-version v1.17.0

minikube status

minikube stop
minikube delete

kubectl veersion

kubectl get componentstatuses

kubectl get nodes


kubectl describe nodes node-1

Microservice deployment to Kubernetes

https://hub.docker.com/r/karthequian/wishlist/

https://hub.docker.com/r/karthequian/wishlist-auth

https://hub.docker.com/r/karthequian/wishlist-catalog

Microservice deployment to Kubernetes

https://github.com/karthequian/wishlist

# Deploying our application to Kubernetes

We're ready to deploy our application to Kubernetes, but let's take a look at our assets.

## Goals:
1. View our sample application and containers
2. Take a look at our deployment file
3. Take a look at our alternate deployment file
4. Deploy our application into kubernetes and verify we can see our API's working.

## Goal 1
View the sample application here:

## Goal 2
To view the deployment file, take a look at wishlist-deployment.yaml

## Goal 3
To see another way to run the microservices, take a look at wishlist-deployment-alernate.yaml

## Goal 4
To run the microservice described in goal #1, from the current directory, run:

`kubectl create -f wishlist-deployment.yaml`

To verify that the deployment is online:
`kubectl get deployments`

To verify that the replica sets are running:
`kubectl get rs`

To verify that the pods are running:
`kubectl get pods`

To see the services:
`kubectl get services`

To interact with your API's in the minikube environment:
`minikube service wishlist-service`

# Wishlist deployment yaml

kind: Deployment

apiVersion: apps/v1

metadata:

  name: wishlist-deployment

  labels:

    app: wishlist

spec:

  replicas: 3 #We always want more than 1 replica for HA

  selector:

    matchLabels:

      app: wishlist

  template:

    metadata:

      labels:

        app: wishlist

    spec:

      containers:

      - name: wishlist #1st container

        image: karthequian/wishlist:1.0 #Dockerhub image

        ports:

        - containerPort: 8080 #Exposes the port 8080 of the container

        env:

        - name: PORT #Env variable key passed to container that is read by app

          value: "8080" # Value of the env port.

      - name: catalog #2nd container

        image: karthequian/wishlist-catalog:1.0

        ports:

        - containerPort: 8081

        env:

        - name: PORT

          value: "8081"

      - name: auth #3rd container

        image: karthequian/wishlist-auth:1.0

        ports:

        - containerPort: 8082

        env:

        - name: PORT

          value: "8082"

---

kind: Service

apiVersion: v1

metadata:

  name: wishlist-service

  namespace: default

spec:

  type: NodePort

  selector:

    app: wishlist

  ports:

  - name: wishlist-port

    protocol: TCP

    port: 8080

  - name: wishlist-auth-port

    protocol: TCP

    port: 8081

  - name: wishlist-catalog-port

    protocol: TCP

    port: 8082

Large Enterprise Application Experience

1. My Early Enterprise Experience
- Team built one big java WAR file
- Ops team deployed to the dev WebLogic Server
- Local development on WebLogic Servers run on own machines
- Environment set up to use the development database via data sources.


2. Ecommerce Catalog
- View the list of current products
- Understand their specifications
- Save into a with lisht that enables team collaboration
- Get a quote for the with list or go through the purchase process.

Three Modules
1) User Module
Responsible for user management, login, and profile management

2) Catalog Module
List of products in the company catalog

3) Wish List Module
API that the customers will user to create and view their wish lists

Our Monolith
- A single WAR file, and has one or more JAR files that provide all of the core functioinality
- Will likely have a common web tier to handle web requests and responses

Breaking This Up
Break the single application into three microservices.
- Auth
- Wish list functionality
- The catalog portion


Benefits of this Structure
- Each microservice has its own Rest APIs that can be userd by the other services

- Reorganize codebase in a more logical way

- Development team can split into smaller feature teams to work on th individual microservices.

- Code and API are more visible to business team

- Individual teams can develop, build, and test their applications locally-team is more productive up front

- Enables containuous integration pipeline

Containers allow you to user Kubernetes.

Transitioning to Microservices
- Addressed some of the microservice building block concrns
- Applied some of the basic principles from the twelve-factor pattern

Our microservices are running in Docker containers, so  let's Kube this up.

Microservice Patterns in Kubernnetes

1. Goal
1.1. Build reference architecture for microservices for Kubernetes

2. Architecture Groupings

2.1. Basic building block architectures
2.1.1. Deployment Patterns
2.1.2. Runtime patterns


3. Building Blocks

3.1. Covers the initial concerns
3.1.1. Codebase
3.1.1.1. Code stored in source control
- Example: Git, Perforce
3.1.1.2. Container images stored in an image repository
- Example: Docker Hub, Artifactory

3.1.1.3. Codebase Workflow
3.1.1.3.1. Push code to your source control.
3.1.1.3.2. Automated build is kicked off to build and run tests against code.
3.1.1.3.3. Bild container image; push to image repository.

3.1.1.4. Image Repository
3.1.1.4.1. Stores your code in an image
3.1.1.4.2. Need to decide early on
3.1.1.4.3. Follow your company guidelines

3.1.2. Dependencies

3.1.2.1. Applications modeled in Kubernetes as Deployments and pods
3.1.2.2. Single pod can have many containers inside
3.1.2.3. Commonly seen in Kubernetes: sidecar pattern

3.1.3. Dev/staging/production parity

3.1.3.1. Dev versus Prod in Kubernetes
3.1.3.1.1. Common Kubernetes deployment patterns
- Small footprint: different namespaces with different credentials for dev, staging, and production

- Large footprint: unique Kubernetes installation for dev, staging, and production


3.1.4. Admin processes.

3.1.4.1. Admin process containers tagged in a similar way to the running application
3.1.4.2. Containers run as Kubernetes jobs/chron job
3.1.4.3. Also run as a separate deployment


4. Deployment Patterns


4.1 Patterns around aplication deployment
4.1.1. Application configurations
4.1.1.1. Applications always have associated configuration to make the application work as expected

4.1.1.2. Application Configuration in Kubernetes
4.1.1.2.1. Two ways to store configs
- configMaps: for generic information(example: metadata, version)
- Secrets: for sensitive data(example:passwords)

4.1.1.2.2. Loaded into the pod via
- Environment variables
- Files


4.1.1.2.3. A Word on Secrets
- Secrets are a good start, but depending on the use case, might need something more like ashiCoprp Vault

4.1.2. Build, release, run
- Tag containers at build time with explicit version
- Don't use latest ta for production containers

4.1.2.1. Running in Kubernetes
- High-level constructs to run containers
- Deployments, DaemonSets, ReplicaSets
- Package management provided by Helm
- Adds revision control


4.1.3. Processes
4.1.3.1. Processes and Port Bindings
4.1.3.1.1. Processes
- Keep application stateless
- Goal: Alllow request to go to any container or server by default

4.1.3.1.2. Statelessness in Kubernetes
- Translated to Deployments and pods
- Deployments comprised of ReplicaSets, which are a collection of one or more pods

4.1.3.1.3. Word on StatefulSets
- Typically used to create persistent storage systems like a MySQK shard

4.1.3.2. Port Bindings
- Containers are implemented in pods
- Communicate to each other via well-defined ports



5. Runtime Patterns
Associating Resources in Kubernetes
- Everything is treated as a service, and configurations are stored in a ConfigMap or Secret

Scenario: Replace a Link to a Database

1) Create new database; ensure it's online and ready to accept connections.
2) Update configuration stored in the ConfigMaps or Secrets.
3) Kill the pods that were communicating with the old database.

When Kubernetes starts up the new pods, the new pods automatically pick up the new configuration, and you'll be using the new service.

If a pod is taking too much load or is receiving a lot of requests, it's easy to scale the number of pods in Kubernetes by adding more to the replica set.

Scaling Kubernetes to handle more traffic is one of the strengths of the platform.



5.1. Patterns for live running systems
5.1.1. Backing services
5.1.2. Features around concurreny
5.1.3. Disposability
The abliity to maximize robustness with fast startup and graceful shutdown

Containers
- Start up fast and run efficiently
- Have all required tooling built inside of the container image

Containers to Pods to Replicas
- Kubernetes manages your containers in pods, which are managed with ReplicaSets
- If one of the pods goes offline, the ReplicaSet will automatically start up a new pod to take its place

Advantages to Users
- From a user perspective, the application will still function, and the user won't see any downtime

5.1.4. Log management

5.1.4.1. Logging
- Treat logs as streams: execution environment handles the logs
- Common to user a log router (Beats/Fluentd) to save the logs to a service(Elasticsearch/ Splunk)
- Kubernetes makes this process easy


6. Some Assembly Required

6.1 Basic Knowledge of Kubernetes required
6.2. Watch the Learning Kubernetes course in the library if needed