SpringOne Platform is the successor of SpringOne 2GX, with a focus mainly on Spring and Cloud Foundry. Next to these technical topics, SpringOne Platform also offered many sessions on cultural transformation and DevOps. Cultural transformation and DevOps are key to deliver meaningful solutions more quickly. This can be achieved by creating empowered teams, able to make independent decisions. To implement these collaborative teams, leadership buy-in is hugely important. Getting away from legacy thinking will allow enterprises to obtain short feedback cycles and thus continuously improve.


From Imperative To Reactive Web Apps - Rossen Stoyanchev

The marquee feature of Spring 5, will be first class support for Reactive Web applications. Reactive programming is about non-blocking, event-driven applications with back-pressure. Back-pressure helps to ensure a good collaboration between producers and consumers. The Reactive Manifesto is an interesting read on this topic.

To support reactive, Spring 5 will use Project Reactor (led by Stéphane Maldini) through the Spring Web Reactive project. This blogpost, by Rossen Stoyanchev is a nice starting point to learn about Flux, Mono and the Spring Reactive world.

Managing Secrets at Scale - Mark Paluch

In a world, where we run large amounts of microservices in orchestrated containers, we can never forget about security, encrypting passwords, storing keys, rotating secrets, etc. Today, applications consume both first and third party APIs and need authentication and authorization to do this in a safe way. Traditional patterns cannot keep the security bar high with dynamic deployment scenarios.

As a Secure-By-Design company, this talk immediately caught my attention. In a Spring world, we can use Spring Cloud Vault Config, wrapping Vault. An interesting tutorial on this Spring library is available on spring.io.

Slides from the talk are available online.

It’s not you, it’s us: Winning over people for yourself and the team - Neha Batra

This was one of the non-technical talks, but aimed to help with the daily management of technical projects. Neha’s session was the most interactive one I attended at SpringOne Platform: about 10 minutes in the session, she wanted us to pair to do a personal SWOT analysis with a stranger in the room and see how we can learn from each other. Everyone participated and I believe this might actually be useful in the context of a project. Something to try out!

She ended her session with a tool chest to prevent and mitigate issues as they come up:

  • SWOT analysis
  • Personal goals
  • Inception
  • Set schedule / cadence
  • Provide feedback
  • Provide a “safe haven”
  • Collect and discuss concerns
  • Talk in person
  • Write down useful conversations
  • Find a way to align first (eg. TDD + pair programming)
  • Daily retros

The slidedeck of her talk is available on Slideshare.

The five stages of Cloud Native - Casey West

Casey West

Another non-technical talk, from the talented and funny Casey West, on how companies are adopting the Cloud Native approach to software development. The talk was very entertaining and resonated with the audience to such an extent, that there was constantly someone laughing. The slides itself don’t say much without explanation so I’ll try to clarify them a bit here.

Analogous to the Kübler-Ross model, there are five stages when adopting Cloud Native development:

Denial

@caseywest immediately grasps the crowd’s attention with these very familiar quotes:

“Containers are just tiny virtual machines”

No they’re not. Stop treating them as such. Moving a huge application or database from a virtual machine to a container doesn’t really solve anything.

“We don’t need to automate Continuous Delivery because we already automate our infrastructure with Puppet”

The problem is that these measures are not enough and they don’t solve enough of the problem. Managing infrastructure and deploying applications using Puppet scripts already is a great improvement by treating Infrastructure as Code but it still requires too much manual labour.

Anger

Again, the goal of these funny quotes is prove a very valid point:

“It works on my machine”

The following quote isn’t in the slides but might also sound familiar:

“Let me do a hotfix, I can figure it out”

and my favourite:

“DEV is just YOLO-ing sh#t to production”

These illustrate the problems, you are likely to get when trying to develop Cloud Native applications without the proper culture in place. This is a clear breakdown in communication and is more a people problem than an IT problem. It just doesn’t work, especially when also considering the compliance or legal aspect. There is a lack of acknowledgement that we need roles and responsibilities.

Bargaining

“What if we create microservices that all talk to the same datasource?”

Single data model and data ownership are not possible this way.

“We crammed this monolith in a container and called it a microservice”

Applications need to adhere to some restrictions to run and scale in the cloud, otherwise you cannot take advantage of the benefits of a platform. Often, there also is the notion of something called bi-modal IT. This is basically dividing your company up into sad mode vs awesome mode.

A lot of organizations believe they don’t need to change and prefer to stay in sad mode, they use bi-modal IT as an excuse. Honestly, nobody really wants to work in sad mode.

Depression

Once people actually start creating Cloud Native applications, the depression kicks in:

“We created 200 microservices and forgot to setup Jenkins”

A common mistake is not to go for a fully automated CI/CD pipeline from the start. This should be your first action when you start a new project. It is necessary to automate your path to production.

“We have an automated build pipeline but release twice a year”

When business is not on board with rapid, iterative delivery, you will never get the desired fast feedback loops.

Acceptance

Finally, everyone start realizing the painful, but obvious truth:

All software sucks

by which he means that creating software is not easy and will never become easy. But we can try to make it as easy as possible for ourselves.

Casey also advises us to respect the CAP theorem, respect Conway’s Law and automate everything.

Also, don’t expect to get all of these things right from the start. Taking baby steps and improving gradually over time is certainly possible. An example is to put a monolith inside a container and start breaking it up into more manageable pieces.

&TLDR;

The (very pretty) slides can be found on Slideshare.

Ordina

Ordina was represented at SpringOne Platform with 2 speakers and 3 talks:

Writing your own Spring Boot Starter - Dieter Hubau

Dieter Hubau gave a very nice introduction on how to write your own Spring Boot Starter. A Spring Boot Starter is the de-facto standard tool for starting with a greenfield Spring project. He started by explaining the magic behind Spring Boot Starters (and @AutoConfiguration) and ended with a cool game of Josh Long Pokemon, deployed on Cloud Foundry.

His slides are available here.

Writing Comprehensive and Guaranteed Up-to-date REST API Documentation - Andreas Evers

Andreas Evers talked about Spring REST Docs to generate documentation that is always up to date. To achieve this, a test-driven approach can be used: generate snippets from integration tests. Combine these snippets with manually written templates and finally generate HTML. Personally, I have always been a huge fan of “documentation-as-code” and Spring REST Docs is a great tool to achieve this goal.

His slides are available here. This blogpost by Kevin Van Houtte provides more insight and examples on Spring REST Docs.

Ignite: Microservices Dashboard - Andreas Evers

On Monday evening, Andreas pitched the Ordina Microservices Dashboard that was released a couple of hours earlier. The Ordina Microservices Dashboard left a big impression:

Microservices Dashboard

Definitely worth checking out. Expect an in-depth blogpost here soon!

Simplifying the Future - Adrian Cockroft

The closing keynote at SpringOne Platform was reserved for one of the most influential people in our industry: Adrian Cockcroft. Always at the edge of technology, Adrian often is credited with making Microservices a mature and useful architectural pattern. His talk focussed on:

  • Simplifying work
  • Simplify the organization
  • Simplify things we build

I really recommend watching his entire presentation on YouTube.

Main Panel Adrian Vegas

Bart Blommaerts is a passionate Software Architect at Ordina, who believes closing the model-code gap is essential to make rapid, agile delivery sustainable. Bart has a strong focus on API design, reuse, automation and security. He is always looking for technical challenges. Bart also is the chairman of the different JWorks Competence Leads at Ordina.