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

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

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.

Links:

Developing Microservices with aggregates - Chris Richardson

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:

  • Entities
  • Value objects
  • Services
  • Repositories
  • Aggregates

About Domain-Driven Design aggregates:

  • Cluster of objects that can be treated as a unit
  • Graph consisting of a root entity and one or more other entities and value objects
  • Typically business entities are aggregates e.g., Customer, Account, Order, Product

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.

Using Event Sourcing with Aggregates:

  • There is no notion of updating the database and then publishing the event but you rather just publish the event
  • For each Domain-Driven Design aggregate:
    • Identify state changing domain events (eg with Event Storming)
    • Define Event classes (for example Order events: OrderCreated, OrderCancelled, OrderApproved, OrderRejected, OrderShipped, …)
  • Persist events and NOT current state
    • Store the events themselves in a database
    • Replay events to recreate state
  • All Aggregates are storing their events in the Event Store, each aggregate subscribes to events of the other aggregates
    • When using CQRS, update the view after processing an event

Benefits of Event Sourcing:

  • Solves data consistency issues in a microservice/NoSQL based architecture
  • Reliable event publishing needed by predictive analytics, user notifications, etc
  • Eliminates object relationship mapping problems
  • Rectifies state changes:
    • Built in, reliable audit log
    • Temporal queries
    • Preserved history

Drawbacks of Event Sourcing:

  • Requires application rewrite (mechanical transformation)
  • Learning curve: weird and unfamiliar style of programming
  • Events can be a historical record of your bad design decisions
    • You will probably implement a mechanism to deal with that such as versioning
  • Must detect and ignore duplicate events:
    • Write idempotent event handlers
    • Track most recent event and ignore older ones
  • Querying the event store can be challenging:
    • Event store might only support lookup of events by identity id
    • Must use CQRS to handle queries meaning application must handle eventually consistent data

Example application: https://github.com/cer/event-sourcing-examples

  • Orders and Customers example with Kafka in between as backchannel
  • Both of them connected with the event store
  • Written in Spring

Summary

  • Aggregates are the building blocks of microservices
  • Use events to maintain consistency between aggregates
  • Event Sourcing is a good way to implement an event-driven architecture

Secure by design - Eoin Woods

Eoin Wood

Eoin Woods went over security and that we should care about it for things like protection against malice, mistakes and mischance, theft, fraud, destruction, disruption,…

He mentioned OWASP top 10 which he approves and should definitely be checked out if you haven’t seen it. There are four aspects of security practice:

  • Secure Application Design
  • Secure Infrastructure Design
  • Secure Application Implementation
  • Secure infrastructure deployment

He explains that there are many sets of security design principles but he notes that there are many similarities between them at a fundamental level:

  • Viege and McGraw (10)
  • OWASP (10)
  • NIST (33)
  • NCSC (europe)(44)
  • Cliff Berg’s set (185)

Out of all these, Eoin has distilled 10 key principles himself:

  • Least privilege
    • Why: Broad privilege allows malicious or accidental access to protected resources
    • Principle: Limit privileges to the minimum for the context
    • Tradeoff: It is less convenient, less efficient and adds more complexity
    • Example: Run a server process with the minimum privileges
  • Separate responsibilities
    • Why: Achieve control and accountability, limit the impact of successful attacks, make attacks less attractive
    • Principle: Separate and compartmentalise responsibilities and privileges
    • Tradeoff: Development and testing costs, operation complexity, troubleshooting can be more cumbersome
    • Example: Admins of a submodule should have no access to other module features
  • Trust cautiously
    • Why: Many security problems are caused by inserting malicious intermediaries in communication paths
    • Principle: Assume unknown entities are untrusted, have a clear process to establish trust, validate who is connecting
    • Tradeoff: Operational complexity, reliability, some development overhead
    • Example: Don’t accept untrusted RMI connections, use client certificates, credentials or network controls
  • Simplest solution possible
    • Why: Security requires understanding of the design, complex design is rarely understood, simplicity allows analysis
    • Principle: Actively design for simplicity - avoid complex failure modes, implicit behaviour, unnecessary features,…
    • Tradeoff: Hard decisions on features provided and needs serious design effort in order to be simple
    • Example: Does the system needs a dynamic runtime config via a custom DSL?
  • Audit Sensitive Events
    • Why: Provide record of activity, deter wrongdoing, provide a log to reconstruct the past, provide a monitoring point
    • Principle: Record all security significant events in a tamper-resistant store
    • Tradeoff: Performance, operational complexity, development cost
    • Example: Record all changes to “core” business entities in an append-only store
  • Secure defaults & fail securely
    • Why: Default passwords, ports and rules are “open doors”. Failure and restart states often default to “insecure”
    • Principle: Force changes to security sensitive parameters. Think through failures - Must be secure but recoverable
    • Tradeoff: Convenience
    • Example: Don’t allow “SYSTEM/MANAGER” after installation. On failure don’t disable or reset security controls
  • Never rely on obscurity
    • Why: Hiding things is difficult - someone is going to find them, accidentally if not on purpose
    • Principle: Assume that the attacker has perfect knowledge, this forces secure system design
    • Tradeoff: Designing a truly secure system takes time and effort
    • Example: Assume that an attacker will guess a “port knock” network request sequence or a password encoding
  • Defence in-depth
    • Why: Systems do get attacked, breaches do happen, mistakes are made - need to minimise impact
    • Principle: Don’t rely on single point of security, secure every level, stop failures at one level from propagating
    • Tradeoff: Redundancy of policy, complex permissioning and troubleshooting, can make recovery harder
    • Example: Access control in UI, services, database, OS
  • Never invent security tech
    • Why: Security technology is difficulty to create, it’s a specialist’s job, avoiding vulnerabilities is difficult
    • Principle: Don’t create your own security technology, always use a proven component
    • Tradeoff: Time to assess security technology, effort to learning it, complexity
    • Example: Don’t invent your own OSS mechanism, secret storage, crypto libs, use existing proven ones
  • Secure the weakest link
    • Why: “paper wall”-problem, common when focus is on technologies and not threats
    • Principle: Find the weakest link in the security chain and strengthen it, repeat (threat modelling)
    • Tradeoff: Significant effort required, often reveals problems at the least convenient moment
    • Example: Data privacy threat met with encrypted communication but with unencrypted db storage and backups

Links:

Event-driven Microservices - Jeremy Deane

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.

Links:

Operating the Spotify backend - Niklas Gustavsson

Niklas Gustavsson

Niklas Gustavsson immediately starts off with the culture at Spotify. Spotify made two very nicely animated videos that explain their culture:

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:

  • See hardware available
  • Specify how much you need like how many instances

They currently do a lot of self-hosting but are planning to fully migrate to Google Cloud Platform.

In order to manage their Docker containers they use Helios which is their own Docker orchestration platform.

Links:

JAX Innovation Awards

The JAX Innovations Awards reward the most innovative contributions in the shape of technology, idea, documentation, industry impact or community engagement.

Most innovative contribution to the Java Ecosystem:

Innovation in Software delivery & DevOps:

Special Jury Award:

Extra: Special Honour Award:

  • Pieter Hintjes (1962-2016) who passed away last week

Day 2

Opening keynote: Decision-making in the face of disruption - Duncan Pearson

Duncan Pearson

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.

Influence on design:

  • Grids with pivots, recalculations, access to formulae everywhere, inline changes to names/formulae/structure
    • It has to support the task-focused application developer
      • Easy screen and navigation design
      • Persistent navigational context
      • Security & access control
    • Completely flexible
      • Anything can happen at any time
      • Remodelling the business should be easy
      • Fast delivery time
    • Scale and perform
      • 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

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.

Bart then listed a couple of the current providers:

  • AWS Lambda
    • Integrates well with all other AWS services
  • IBM Bluemix OpenWhisk
    • OpenWhisk is open source and available on Github
    • Better UI than AWS and also has a dashboard for monitoring
  • MS Azure Cloud Functions
    • Mature system
    • 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.

Serverless demo setup

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:

  • Scaffolding
  • Best practices (grouping of functions)
  • Lifecycle support (create, deploy, invoke,…)

The demo and code samples are available at:

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.

Links:

Four Distributed Systems Reference Architectures - Tim Berglund

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.

Strengths

  • Potentially low resource cost
  • Rigorous microservices discipline

Weaknesses

  • Can be very complex
  • Requires a different way of thinking

Rating

  • Scalability: 4/5
  • Hipness: 5/5
  • Difficulty: 5/5

Links:

Yannick is a principal Java consultant and practice manager at Ordina Belgium. He’s passionate about everything Java, Spring and cloud related as well as reactive programming, Kotlin, Lightbend technologies, software architectures, and coaching and enabling other colleagues.