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!
Virtual Machines
Containers
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
