Development

in the Cloud

DevOps Foundation

Microservices

Architecture

Hybrid

Integration

DevOps

Foundation

Lean Thinking

Application Development Lifecycle

Application Development Lifecycle

Application Development Lifecycle

Application Development Lifecycle

Application Development Lifecycle

Application Development Lifecycle

IBM Software

Development Improvement with DevOps

Bendigo Bank Development Activities Improvement

Microservices

Architecture

Monolithics VS Microservices

Why Microservices?

1. Multiple Technology

Why Microservices?

2. Independent Scalability

Why Microservices?

3. Resiliency with Bulkhead

Why Microservices?

3. Independent Lifecycle

Why Microservices?

4. Composability

Building Microservices

Breaking up the monolith

Building Microservices

From Cloud-ready to Cloud-native

Building Microservices

1. Codebase

Strictly One Codebase per One App (1-1 relationship)

Building Microservices

2. Dependencies

- Never relies on implicit existence of system-wide packages.

- Do not rely on the implicit existence of any system tools.

- The new developer can check out the app’s codebase onto their development machine, requiring only the language runtime and dependency manager installed as prerequisites.

Building Microservices

2. Dependencies

Building Microservices

3. Config

- An app’s config is everything that is likely to vary between deploys (staging, production, developer environments, etc)

- JDBC url, Storage credential, SMTP credential, etc 

- Strict separation of config from code. Config varies substantially across deploys, code does not.

- Stores config in environment variables 

Building Microservices

3. Config

Building Microservices

4. Backing Services

- Treat backing services as attached resources

- Makes no distinction between local and third party services

- A deploy of the twelve-factor app should be able to swap out a local MySQL database with one managed by a third party

Building Microservices

4. Backing Services

Building Microservices

5. Build, release and run

- Strict separation between the build, release, and run stages

- Every release should always have a unique release ID

- Builds are initiated by the app’s developers whenever new code is deployed.

Building Microservices

6. Processes

- Processes are stateless and share-nothing

- Any data that needs to persist must be stored in a stateful backing service, typically a database or memcache

- The memory space or filesystem of the process can be used as a brief, single-transaction cache. 

- Never assumes that anything cached in memory or on disk will be available on a future

Building Microservices

7. Port Binding

- Exports HTTP as a service by binding to a port

- In deployment, a routing layer handles routing requests from a public-facing hostname to the port-bound web processes.

- An app can become the backing service for another app, by providing the URL to the backing app as a resource handle in the config for the consuming app.

Building Microservices

8. Concurrency

- Architect an app to handle diverse workloads by assigning each type of work to a process type

- App processes should never daemonize or write PID files

Building Microservices

9. Disposability

- Can be started or stopped at a moment’s notice

- This facilitates fast elastic scaling, rapid deployment of code or config changes, and robustness of production deploys

- Minimize startup time

- Shut down gracefully when they receive a SIGTERM signal

- For a worker process, graceful shutdown is achieved by returning the current job to the work queue.

Building Microservices

10. Dev/prod Parity

- Keep development, staging, and production as similar as possible

- Make the time gap small: a developer may write code and have it deployed hours or even just minutes later.
- Make the personnel gap small: developers who wrote code are closely involved in deploying it and watching its behavior in production.
- Make the tools gap small: keep development and production as similar as possible.

Building Microservices

11. Logs

- Treat logs as event streams

- App never concerns itself with routing or storage of its output stream

- The event stream for an app can be routed to a file, or watched via realtime tail in a terminal.

- Most significantly, the stream can be sent to a log indexing and analysis system such as Splunk, or a general-purpose data warehousing system such as Hadoop/Hive.

Building Microservices

12. Admin Processes

- Run admin/management tasks as one-off processes

- Admin code must ship with application code to avoid synchronization issues.

- They run against a release, using the same codebase and config as any process run against that release.

Building Microservices

Breaking up the team!

Docker

A Container Technology

FROM ubuntu:12.04

MAINTAINER Touchapon Kraisingkorn

RUN apt-get update
RUN apt-get install -y apache2
RUN apt-get clean
RUN rm -rf /var/lib/apt/lists/*

ENV APACHE_RUN_USER www-data
ENV APACHE_RUN_GROUP www-data
ENV APACHE_LOG_DIR /var/log/apache2

EXPOSE 80

CMD ["/usr/sbin/apache2", "-D", "FOREGROUND"]

Hybrid

Integration

Composable Enterprise

Composable Enterprise