1. Architecture
2. DevOps
3. Server Stack
4. Client Stack
5. Profit!
Enterprise Architecture
Enterprise Architect
-
Don't have one - shared responsibility.
-
Self organising team
-
But we make decisions a lot faster.
-
We do have some Enterprise Architect Jokes instead
Service Evolution
Sources: PWC research
Developer Evolution
We Had
Traditional layered architecture:
- Silo'ed teams of BA, Designers and Dev (Conway's Law).
- Delivery bottlenecks
- Lack of collaboration and re-use
- Frustrating to debug/support
- Difficult to deploy
We now have:
MicroServices based architecture:
- Cross functional design/dev of services
- Parallel delivery
- Re-usable modules across client and server
- Easy monitoring and diagnostics.
- Continuous Delivery
Architecture
Communal Design Decisions
KISS
(Keep It Simple Stupid)
No App Servers/War
- Bloated in size, hogs resources, memoryleak, restarts
- Another layer of configuration and complexity
-
Run multiple apps1 app per server, no isolation -
Provide Infrastructurepart of the app - Ops - provides own toolsets vs external choices.
- EJB support - no need in this day and age
- $$$ and require specialists
Use Standalone Apps
- Self contained
- Configure you app, not the app server
- Resource isolation via docker containers
- Java - Jetty; Netty, Undertow, or just Main()
- Node.js - Harp, Express
- Ruby - Rails, Sinatra
- More on Framework later
Reference: Heroku for Java
Enterprise Service Bus
- solves all integration problems in a box
- fail proof
ESB In Reality
One massive app server with all the same issues
MicroServices
- Decentralised Governance
- Decentralised Data
- Independently Scalable
- Fault Tolerant
- Smart endpoints
- Free
vs ESB
- Central orchestration.
- Canonical Data Model
- Middleware Bottleneck
- Single point of failure
- Smart Pipeline
- $$$$$$
Need pub/sub or queuing: try light weight broker-less messaging such as ZeroMQ.
JSON/REST
vs SOAP/WSDL
{
"streetNumber": "80",
"streetName": "Clarence",
"suburb": "Sydney"
}
Text
<?xml version="1.0" encoding="UTF-8" ?>
<Property>
<streetNumber>80</streetNumber>
<streetName>Clarence</streetName>
<suburb>Sydney</suburb>
</Property
PUT /hostname/properties/
<service name="Properties">
<documentation>WSDL File for PropertyService</documentation>
<port binding="tns:Properties" name="Properties_Port">
<soap:address location="http://hostname/propeties/" />
</port>
</service>
Swagger
- Who needs WSDL or JavaDoc when you have Swagger
#YoloSwag!
Dev Ops
Who Does Dev Ops
- No one does Dev Ops for the sake of Dev Ops
- DevOps is a means to an end: build good software
- Every good engineer should be Dev Ops minded
Continuous Delivery
1. GitHub triggers artefact Snap-CI pipeline
2. Upload tested artefact to Bintray
Continuous Delivery
3. Push to Quay.io to build Docker
4. Run Container on Tutum PaaS
Continuous Delivery
5. Monitor Services using NewRelic
Why Docker
- Resource Isolation
- Immutable and Portable
- Lightweight compared to VM
Small and Fast Docker
- Take advantage of caching in Dockerfile
- Use small base images: Alphine, BusyBox
- CI friendly: fast build is a good build
Server Stack
Picking a Framework
- Use the right tool for the right job
- Do prototype spikes that cover key requirements
- Consider the learning curve and team skill set
- Infrastructure are on-demand, don't feel restricted
- Performance will matter eventually, but not day 1
- Reference TechEmpower benchmarks, or roll your own
TechEmpower Benchmarks
Don't always believe the hype!
Frameworks we use
- Rails - the original developer productivity framework
- Dropwizard - Production ready out of box
- Spring Boot - For when you really need Spring
-
RatPack- Not so easy to do the right thing
Gradle
vs Maven
repositories {
jcenter()
maven { url "http://dl.bintray.com/trunkplatform/osworkflow" }
}
}
dependencies {
compile group: 'com.trunkplatform.opensymphony', name: 'osworkflow', version: '3.1.4'
}
<repositories>
<repository>
<snapshots>
<enabled>false</enabled>
</snapshots>
<id>bintray-trunkplatform</id>
<name>bintray</name>
<url>http://dl.bintray.com/trunkplatform/osworkflow</url>
</repository>
</repositories>
<dependencies>
<dependency>
<groupId>com.trunkplatform.opensymphony</groupId>
<artifactId>osworkflow</artifactId>
<version>3.1.4</version>
<scope>compile</scope>
</dependency>
</dependencies>
Postgres and MySql
- Trnk.io - MySQL via Google CloudSQL
- Platmasphere - Postgres via Amazon RDS
- Postgres offers multi-tenant functionality
Dependency Injection
- Inject dependencies as needed, rather than passing through different constructors.
- Swapping in stub implementations for tests
- Spring and Guice equally good. Right tool for right job
Pact
Client Stack
AngularJS
- MVC
- Dependency Injection
- Static pages
- Made by Google (?)
Gulp
- http://markdalgleish.github.io/presentation-build-wars-gulp-vs-grunt/
- Streaming Builds
gulp.task('package', function() {
return gulp.src([ 'app/**/*', 'gulp_tasks/*', 'newrelic.js', 'package.json' ], {"base": '.'})
.pipe(tar('platmasphere-client.tar'))
.pipe(gzip())
.pipe(gulp.dest('.'));
});
Harp
- Simple lightweight webserver
- Precompiles CSS and HTML templates
- No need to write any server app code
var express = require('express')
var app = express()
app.get('/', function (req, res) {
res.send('Hello World!')
})
var server = app.listen(9000, function () {
var host = server.address().address
var port = server.address().port
console.log('Example app listening at http://%s:%s', host, port)
})
bash$ harp server .
------------
Harp v0.14.0 – Chloi Inc. 2012–2014
Your server is listening at
http://localhost:9000/
Press Ctl+C to stop the server
------------
Profit!
Questions
MicroServices and Friends
By Yun Zhi Lin
MicroServices and Friends
Platmasphere Tech Stack
- 6,247