Menu

JAX London 2016

JAX London is a four-day conference for cutting-edge software engineers and enterprise-level professionals. JAX brings together the world’s leading innovators in the fields of Java, microservices, Continuous Delivery and DevOps.
For this year’s slogan they decided on: “Create, Innovate, Code”.
Ordina was present at JAX London on the 11th and 12th of October 2016 where one of our colleagues, Bart Blommaerts, also presented a talk on The Serverless Cloud.
In this blogpost we want to give the highlights of some of the talks we followed.

Day 1

Introduction to JAX London - Sebastian Meyen

To start off, Sebastian Meyen, program chair of the JAX conferences, gave an introduction to JAX London.
He mentioned that only half of the attendants of JAX originate from the UK, making it an international conference.
JAX is all about “openness”, we should be celebrating open source and embrace open source thinking as it makes our code smarter.
Java is one of the most powerful ecosystems out there according to him and it comes with a unique culture.

Sebastian explained that there are different cultures within a company:

Pioneers: They go into the wild and experiment and although they might fail often, they’re looking at what the next big thing might be

Settlers: They make a valid business model based on the results of the research of the pioneers and make stable technology for it

Town builders: They look at the portfolio of the settlers and decide what to industrialise, they want to create volume

He stresses that innovation happens on all three levels and not just only at the pioneers or settlers.
Furthermore he went briefly over the different genres of the talk and the conference app before introducing James Governor.

Opening keynote: Java for Cloud Natives - James Governor

James Governor opens up his talk by showing how Java is still high on the Programming Language rankings despite the “Java is dead”-doomspeak every now and then.
Regarding Java frameworks, Spring and Spring Boot are really crushing it.
He also mentions that most startups usually start with a new and fancy language but as they mature, a lot of them actually turn into Java shops.
Examples of this being: Uber, LinkedIn, Netflix, Twitter, Amazon, Etsy, Facebook, Yahoo and Google.

Twitter for example started in Ruby and during the US presidential election in 2012 they migrated to Scala and Java on the JVM for scalability and performance reasons.
After the migration they managed to sustain peaks of TPS (Tweets Per Second) for hours, at one point even reaching 15,107 TPS.

James went through a couple of companies and the transformations they underwent for staying competitive.
Amazon for example started with a messy code base but they did manage to refactor it.
Being a top down company, they also managed to create small teams.

Netflix is a similar case, at a certain point they had a messy codebase but they really put a lot of effort into refactoring it.
They also invested a lot in their software engineers and continue to do so.

Open source is the new normal, there are a lot of cool open source frameworks around that you can contribute to such as Zookeeper, Spark, Kafka, Hadoop, Giraph, Jenkins, Cassandra,…
It’s awesome when enterprises contribute to open source.

Bosch: They are doing interesting work with Eclipse Foundation, they know they need to do open source so they make open source contributions

Comcast: Everybody hates Comcast in the US, but they are making open source contributions

James mentions a couple of things he finds important:

Microservices and container based deployment such as Docker and Kubernetes are very hot topics

Break down the technical model and teams

Continuous integration is very important, there are still people not using it!

Make people responsible for their own Quality Assurance

Embrace failure and graceful degradation

Finally, he mentioned that there is always the need to deal with the politics and that governance is still important and needed.
Oracle needs to give their commitment to Java and the Cloud and we as a community need to encourage Oracle to step up and not only complain about them.

Developing Microservices with aggregates - Chris Richardson

The goal of Chris Richardson’s presentation was to show how Domain-Driven Design aggregates and microservices are a perfect match.

A microservice based architecture tackles complexity through modularisation.
A microservice should be seen as a business capability for example a catalog service, review service or order service.
By having service boundaries you enforce modularity.
Also important to mention is that each microservice needs to have its own database, microservices do not share a database!
Finally there should always be an API gateway in front of the microservices, which is the entrypoint for the frontend user interface and mobiles devices.
They should never access your microservice directly!

Chris strongly suggest reading Domain Driven Design by Evan Evans.
The core building blocks of Domain-Driven Design are the following:

Chris talked about the problems you have to handle when dealing with microservices and that practicing Domain-Driven Design can help you a lot to address these.
He mentioned that you would probably ask yourself how you can enforce invariants if the microservices reside in different JVMs.
You would be reliant on ACID transactions to maintain consistency.
Transactions violate encapsulation and require 2-Phase Commits (2PC) which is not an option because of the following reasons:

It guarantees consistency but 2-Phase Commit is a single point of failure

It is a chatty protocol: at least O(4n) messages, with retries O(n^2)

Reduced throughput due to locks

Not supported by many NoSQL databases (or message brokers)

Doesn’t fit in a NoSQL mindset

Aggregates are a solution to these ACID transactions since they allow you to use eventual consistency.
You reference other aggregate roots via an identity, this being the primary key.
If an update must be atomic then it must be handled by a single aggregate therefore aggregate granularity is important.
You should have your aggregates as fine grained as possible.
In an Event-driven architecture you can work with steps where each step publishes an event that trigger the next step in the sequence.
You will need to write custom logic to compensate the well known ACID transaction rollback so careful design is required.

Event-driven Microservices - Jeremy Deane

Jeremy Deane starts off telling that within Event-driven architectures (EDA) you have events representing a snapshot in time of an occurrence within a system.
We should distinguish the following Enterprise Integration Patterns (EIP):

Event Message

Command Event

Event Sourcing

As for possible Middleware solutions:

ActiveMQ (JSM), RabbitMQ (AMQP)

Kafka, ZeroMQ

Akka

There are a couple of EDA principles to take in mind:

Events are emitted by a Producer and received async, and optionally acted upon, by a stateless Consumer

Streams are sets of related Events

Intermediate Processors can enrich the raw Event

Ideally, Producer and Consumer should be decoupled so they can evolve independently over time

Producer should be a magnanimous writer and consumer should be a tolerant reader

Consumers can listen to Event Queues or subscribe to Event Topics

To give some EDA examples:

Fraud prevention

Medical Alerting (ER check-in)

Financial Portfolio Management

Supply Chain Management

Microservices Architectural Style:

Application as a suite of small services

Each running in its own process

Communicating with lightweight mechanisms

Built around business capabilities and independently deployable by fully automated deployment machinery

Bare minimum of centralized management

Jeremy really likes Apache ActiveMQ for several reasons:

Not the fastest but the easiest to implement and maintain

Easy to learn

Great and active community

High Availability via a master/slave approach

Finally he did a demo of an application built with ActiveMQ and Apache Camel to show how well and easy they integrate together.
The source of the demo is available at the links below.

Basically it comes down to having autonomous teams called squads containing of 7-12 team members:

A squad should be fully staffed for their “mission”

A squad can decide how they want to tackle their issue

Each squad is on call for their own microservices

At Spotify they have hundreds of fairly small services that only do one thing well.
Each service is owned by a squad that implements and deploys it into production.
Later on, they started putting ops guys in the squads in order to be able to tackle issues a lot faster.
Jeremy also stresses that it’s very important to automate as much as possible.

At Spotify they have a simple incident process to avoid the same issues from reappearing:

Something explodes, an incident gets created and it gets fixed

(Blameless) post-mortem meeting

Remediations to make sure it never happens again

The incident is closed

System-Z is the service registry in which all services in production get registered in and the following information is available for each microservice:

Who’s on call for each service

When a service is down

What the dependencies are for each service

The hardware in use

The amount of instances

Also, in order to encourage squads to register their microservices, if you’re not registering your services in there you’re not getting any hardware and thus you can’t get your service into production.

In order to maintain their hardware they utilise the Cortana Pool Manager where they have the following information available:

Day 2

Duncan is a Chief Architect at Anaplan.
Anaplan is the leading planning and performance management platform for smart business.
It provides a mechanism that helps the business understand the consequences of what they intent to do.

Duncan first sums up the forms of disruption:

Market replacement

Film -> Digital camera

Digital Camera -> smartphone

GPS -> smartphone

Market change

Free online ad-funded services

Comparison websites

New market

Personal gene technology

Recorded music

Environmental change

Natural disaster

War and civil unrest

Time is of the essence and it is important to act quickly to a window of opportunity when trying to tackle a changing situation over time.

There are two perspectives on disruption:

The disruptors

High organisational growth leading to complexity transitions

High sensitivity to: growth rate mismatch and delay effects

For example: DataStax, Facebook, Salesforce, Groupon, Box, OpenDNS

The disrupted

New business models required

Disconnect between business functions and supporting systems

Entrenched organisational systems

For example: Yahoo, Toyota, PWC, Verizon, Vodafone, Cisco

Duncan mentions that there are two kinds of systems: modelling systems and execution systems.
A good modelling system has the following characteristics:

Personal

Flexible

General purpose

It has to feel like a spreadsheet

Whereas a good execution system tends to be:

Specialist, use-case-specific

Embed the “model” in the software

Secure / multi-user

User-task focused

An execution system tends to be a system that has already been analysed in-depth.

If it looks like a spreadsheet then it had better behave like one even if you are changing billions of numbers

A business management tool

No programming

No DB design required

Influence on the company:

We were the disruptor, on a tight deadline

Success through simplicity

Something that works today is better than something that is right tomorrow

Led by our customers, driven by the features that they need

We are undergoing inevitable complexity transitions

New HR systems, management processes, multiple dev locations

Standard Compliance (security, development process)

The Serverless Cloud - Bart Blommaerts

Bart Blommaerts starts off explaining that serverless, although as suggested by the name, does not actually mean that you’re not using any server.
What it does mean is that the existence of a server is hidden for you.
The name might be a bit misplaced and it would be more correct to simply call it Functions as a Service (FaaS).
Serverless or FaaS might actually be the next step in the evolution of cloud computing.

Going serverless will lead to less worries seeing as you no longer have the server management to take care of.
Security updates, scalability and availability is all taken care off for you, by the provider.
On the other hand, more trust must be put into the provider.

The need for an ops team will not fade since you still need to take care of things such as monitoring, debugging support, memory management, application configuration and more.
All these things could be handled by a specialised, outsourced team.
Seeing as serverless is rather new, there is also the opportunity for tooling to be built!

We can distinguish the following characteristics:

Event-driven

Pay per execution instead of server uptime

The actually invocation cost depends on how long it took to execute the call

An example of the pricing of AWS:

Pay per 100ms minimum each call

3.2 million free tier seconds per month

Outside of the free tier the price per 100ms is $0.000000208

Serverless comes with seamless scaling:

No risk of under- or over-provisioning

Short-lived “compute containers” that:

are isolated from other functions

have their resources provided from the function config

may be reused

Serverless is stateless, there is no state persisted in between invocations.
In order to preserve state you can still use a db, file system or cross-application cache.

Different payment model compared to AWS that could be more expensive in the long run

Google Cloud Functions

A new initiative by Google, but it benefits from services Google offered over 5 years ago

Currently reimplementing it

Currently in private alpha

Very active community

Auth0 WebTask

CLI

Really simple to use, you can be up and running in 30 seconds

Well documented with examples

Serverless enables experimentation due to how easy it is to get something up and running and the low running costs.
It could lead to a more collaborative economy seeing as a lot of companies are sitting on a ton of data currently not being used.
All this data could be made public by publishing an API and others could consume the data and combine it with their own data, enriching it.
In Belgium there is already a company, Realo, that only combines data and they seem really popular.

Bart did a demo using an Arduino measuring the temperature.
The Arduino then sends the data off to multiple providers, enriching the data, after which it gets logged in the final step.

During the demo, Bart mentioned that he used the Serverless Framework for development.
The Serverless Framework is a CLI, soon to be supplier independent (at the time of writing), with the following features:

Bart notes that the size of the function is important as it has an impact on execution time and will affect the cost.
For example a service written in Java could be 34MB whereas in NodeJS the exact same function may only be 100KB.

Best practices:

Compare the following regarding supplier choice:

Integration

Offering

Tooling available

Execution time is limited so check if it fulfils your needs

SLA available?

Code

Initialise services outside of the function such as making a database connection

Limit function size

Use an external editor and a VCS

Bart also recently wrote a blogpost on The Serverless Cloud, you should definitely check it out if you’re interested on the subject.

Four Distributed Systems Reference Architectures - Tim Berglund

According to Tim Berglund, a distributed system is a collection of independent computers that appear to its user(s) as one computer.
Independent computers should operate concurrently, fail independently and should not share a global clock.

The point of Tim’s talk is to compare the following four systems:

Modern 3-tier Architecture

Sharded Architecture

Lambda Architecture

Serverless Architecture

Each system has its strengths and weaknesses compared and finally receives a rating for the scalability, hipness and difficulty of use.

Modern 3-tier Architecture

The classic Presentation, Business and Data tier.

Before: JSP, EJB/Servlet, Oracle DB

Now: React.JS, Node.JS, Cassandra

Strengths

Rich front-end framework (scale/UX)

Hip, scalable middle tier (such as Spring)

Basically infinitely scalable data tier

Weaknesses

State in the middle tier

Rating

Scalability: 4/5

Hipness: 2/5

Difficulty: 3/5

Sharded Architecture

With a Sharded Architecture the Business and Data tier is usually sharded.
In between the clients and the business tier there’s usually a router that performs loadbalancing and routes the request to the service of the application.
The Data tier contains multiple databases.

Strengths

Client isolation is easy (data and deployment)

Known, simple technologies

Weaknesses

Complexity

No comprehensive view of data

Oversize shards

Rating

Scalability: 3/5

Hipness: 1/5

Difficulty: 4/5

Lambda Architecture

Streaming data versus handling data in batch or even better, unbounded data vs bounded data.
Event-driven, events are either stored in a database or processed via an Event Processing framework such as Apache Storm.

Storing them in a database includes:

Long-term storage

Bounded analysis

High latency.

On the other hand, processing them via an Event Processing framework includes:

Temporary queueing

Unbounded analysis

Low latency

Strengths

Optimises subsystems based on operational requirements

Good at unbounded data

Weaknesses

Complex to operate and maintain

Bad at mutable/update-in-place data

Rating

Scalability: 3/5

Hipness: 3/5

Difficulty: 5/5

Serverless

Does not mean that there isn’t any server, just that you no longer maintain it.
Also called Functions as a Service (FaaS), these can be seen as “extreme” microservices.

Yannick is a senior Java consultant and competence lead of the JVM languages competence center at Ordina Belgium. He’s very much interested in everything Java and Spring related as well as reactive programming, Kotlin, Lightbend technologies, software architectures, and coaching and enabling other colleagues.