MicroXchg

In this talk, Head of Engineering Rodrigue Schaefer will discuss some of the challenges of Zalando's transition from monolith to microservices and how the company’s engineering team has tackled them through a combination of organizational decisions and development of new tools. He’ll discuss Zalando’s open-source PaaS framework STUPS (stups.io), which was built in-house to enable multiple teams to use the full power of AWS without scarifying vital aspects like security, traceability and architectural standards. Docker has played a key role in this architectural transformation and helps us to realize an easy and robust deployment process. 
Rodrigue will also discuss how Zalando engineers are taking a microservices approach to front-end as well as back-end, through a rebuild of the company’s “shop”—the unit that includes our 15 country-specific, customer-facing websites. He’ll describe how the team is using tools like Hystrix and various resilience libraries to manage its growing microservices ecosystem. Finally, he’ll explain how microservices has enabled Zalando’s tech team to achieve a culture of autonomy, mastery and purpose that encourages innovation and experimentation.

Go faster than your competitors. That’s the promise of microservices – deploy faster, scale faster, be more robust. It’s all about outcomes and the way your organisation is structured has a tremendous impact on those outcomes. it’s easy to say “Conway’s Law” and then move swiftly on. “But but but, but how?”

In early 2014, James and Martin Fowler called out “Organised around business capabilities“ as a core characteristic of microservices. This was based on feedback from successful teams around the world about how important this aspect was on the systems they were building. In this talk, James explores some of these structures and provides some practical guidance on what he and Martin meant when they said “business capability”.

Splitting our organization in smaller, autonomous teams and dividing our product JUST SOCIAL into single collaboration apps was the driving force to transform our monolithic system architecture into microservices. During this talk I would like to share some experiences we made during our microservices journey - especially when facing the challenge to distribute the product in the cloud AND as on-premise solution. 

Spring Cloud is an umbrella project that provides a variety of modules to support developers facing challenges typical in a microservices context: service discovery, resilience, distributed tracing etc.

The talk starts with a brief introduction into the project and recap overall, followed by an in depth update on the recent additions to the project: distributed tracing with Zipkin, support for HashiCorp's Consul and Apache Zookeeper, advanced support for messaging, a new cluster module as well as improved CloudFoundry integration.

A core aspect of a microservice architecture is individual deployability of services. Thus, orchestrating the roll out of these services should be as easy as possible. Historically Netflix has rolled out deployments using an open-source tool called Asgard. Spinnaker – the successor of Asgard and an open-source project as well – is a complete reimplementation of its predecessor and heavily improved.
The talk introduces Spinnaker, the challenges it's trying to solve as well as the core concepts it's talking about. We then discuss and demo setting up a build pipeline as well as the various options in deployment targets, rollout strategies etc.

Full blown virtual machine or containers seems to be a huge question today. But there is an often ignored option: Unikernels. These are minimal kernels thatare just built to support just one application on top of a hypervisor. Insteadof having an additional kernel layer like containers, they work by never providing things an app doesn't need and rely on hypervisors for isolation.Like containers, the idea is not new, but the first implementations are comingto a practically usable state. Which leaves us with a question: how do we develop software on top of them?
This introduces you to the rumprun unikernel and development on it. It features examples as well as a comparison with other systems.

When architecting an enterprise Java application, you need to choose between the traditional monolithic architecture consisting of a single large WAR file, or the more fashionable microservices architecture consisting of many smaller services. But rather than blindly picking the familiar or the fashionable, it’s important to remember what Fred Books said almost 30 years ago: there are no silver bullets in software. Every architectural decision has both benefits and drawbacks. Whether the benefits of one approach outweigh the drawbacks greatly depends upon the context of your particular project. Moreover, even if you adopt the microservices architecture, you must still make numerous other design decisions, each with their own trade-offs.
A software pattern is an ideal way of describing a solution to a problem in a given context along with its tradeoffs. In this presentation, we describe a pattern language for microservices. You will learn about patterns that will help you decide when and how to use microservices vs. a monolithic architecture. We will also describe patterns that solve various problems in a microservice architecture including inter-service communication, service registration and service discovery.

1) Microservices - with Monolith and other Diseases (Felix Müller)

Ongoing microservice transition since 2 years. Rotting distributed monolith in the background and still alive. And independent development teams as our ultimate goal. Join our journey to Microtopia. In this talk I show you which problems we had to solve at E-Post since our microservice transition started. How do we set up 10 teams and empower them to work independently on their services? And which nifty challenges arise when you try to adapt your organizational structure to microservice architecture style. There is no silver bullet. I talk about our solutions and experiences with architectural constraints, technology stacks and humans.

2) Challenges in adopting microservices for an internal service eco-sytem in a large corporation. (Shahzada Hatim)

Before his current assignment the speaker had a year long opportunity to work for a corporation where microservices were chosen as the primary method of encouraging software re-use among independent business initiatives. The speaker and his team faced many challenges in adopting microservices architecture on top of the usual riddles of corporate software development. The challenges presented in this talk are specific to the case being described. However there are some learning pertinent for audience at large which this lightning-talk will summarise.

3) Why microservices are not worth it! -- the long list of tradeoffs (Florian Thiel)

Architecture decisions always involve tradeoffs. A Conway-structured organization, risk reduction through small services and massive scalability sound like dream-come-true arguments for abandoning your monolith and joining the microservice camp. Although nobody expects the transition to miroservices to be easy, I will argue that there is a very long list of often overlooked (or deemed very cheap) challenges. And maybe there is room for compromises... 

Here we are: Microservices, Container, Cloud ... and lots of data to deal with. Usually that's where the real trouble starts. Many developers still base their designs on the concept of perfectly consistent ACID transactions, everything being always consistent and in order, no anomalies around.
But reality is different: Perfect consistency does not exist and many real-world use cases require much weaker consistency models in order to satisfy the scalability or robustness requirements.
So, what are our options and what is the price we need to pay? Do we need to accept potentially losing data in order to get higher availability? How much can I scale without compromising consistency?
In this session we will answer this and many more questions. We will also have a look at some popular data stores and examine what kind of consistency models you can achieve with them and how. Finally, we will have a peek into latest research and see new ideas that might push the borders of the current state-of-art.

This presentation gives an overview of the technical solutions for the orchestration of Docker based services and why it is so important for you to rethink your Microservice systems. To create, maintain and modify many machines and containers on your developer notebook, in the data center or the cloud is a challenge. Our applications are constantly being expanded and adapted to different use cases. The Docker ecosystem offers promising tools for service discovery, automatic scaling, failover and deployment. The talk presents the benefits of the tools and shows a practical Microservices system environment.

We're deeply sorry if you decided to deploy a new product in 2016. Not only are systems getting more and more complex, but you're spoiltby the choice between oodles of infrastructure solutions. But donot fear as Docker is here. Containerization set out to redeem you from all your ops hassle. But since there are still minor inconvenienceslike Networking, Service Discovery, Persistence of even Security to be takencare of, your job isn't done with containerizing everything. All of the aboveare fundamental architectural decisions you shouldn't approach reckless.
While Hashicorp tools are no silver bullet, they allow for pragmatic solutions while you still remain at the wheel. We want to show you how to set up an infrastructure suited for modern software needs.
Disclaimer: We're not affiliated by any means with Hashicorp. We just happen to like their tools a lot ;-)

MicroServices implemented within a traditional IT structure will, at best, provide no benefits. To truly exploit the flexibility and raw deployment speed of MicroServices, complementary technology, IT processes, business interactions, and even roles and responsibilities must be adjusted. In this talk, we explain in plain language the reasons changes are essential. Further, we delve into solutions we have used in practice to create successful MicroService organizations.Complementary and Necessary Support for MicroServices

Chris Richardson, Russell Miles, Sam Newman, Stefan Tllkov and Susanne Kaiser join Eberhard Wolff for an open discussion about the do’s and don’t’s of microservices. We will try to get the audience to ask the most important questions that are still open after the first day of the conference, and make sure we address the skeptics’ arguments. Have anything you’d like Eberhard to ask the panelists? Send him your favorite question to @ewolff on Twitter or be there when our panel starts to ask it yourself.

With more and more teams using the microservice architecture, and gaining the speed of delivery benefits that it provides, a challenge has emerged in teams that do not have sufficient experience with message-oriented systems. The network is unreliable, has many moving parts, and it’s easy to end up in bad places. Avoiding the curse of the distributed monolith, and avoiding catastrophic failure, are immediate issues facing many new microservice systems. In this talk, a careful analysis is made of the many byzantine ways in which message-oriented systems can fail. A set of remedial approaches is presented, and an empirical report on there effectiveness will also be made. This talk will provide developers with some practical tactics to keep their microservice architectures healthy and performant.

Microservice API styles, service lookups, datastores, scaling – all of our typical discussions about microservices seem to be centered around backend topics. But what about the user interface? How are we supposed to structure what is arguably the most important part of our applications – the one facing our users? In this session we’ll explore the role of the UI aspect in a microservice architecture, look at various methods of modularization, and derive a set of guidelines for avoiding monolithic frontends.

Microservices promises faster development, deployments, scaling and all the goodies you always wanted but never had. Highly scalable services like Netflix and Soundcloud have successfully integrated micro services not just as a way of application development, but as a structure of how the organisation runs. Over the past year, I have worked on a transformation project which was inspired from success stories of these organisations and adopted micro services to help move away from a monolithic system to deliver value to end users quickly and reliably. We were often faced with cultural, technical, and geographical challenges around harnessing the goodness of micro services which is very different from adopting them in a startup environment.
In this talk I will share my top lessons - these include both successes and failures - which were often difficult to digest. Most importantly, I will share the successes that at the time, looked like failures.

The end to end response time of a network of microservices tends to have a wide distribution with a long tail at the 99th percentile, even if the mean is short. By collecting the response time distributions and throughput for request traces we can see how the individual microservices respond, but to combine these distributions and find which microservice is contributing the most to the 99th percentile requires application of montecarlo simulation. This talk will explain how this technique works and investigate tools ranging from Excel plugins to R packages that can implement montecarlo models.

While many organizations are keen on breaking up their monolithic applications and establishing microservice architectures, only few of them truly appreciate the impact on runtime information like log data and metrics. But without it you are almost blind in production. And without correlating events from different sources it becomes very difficult to make sense of your metrics and to draw accurate conclusions. If you want to break monoliths into a variety of distributed services, standard approaches are no longer sufficient.
In this session, we will show the conceptual foundation and best-of-breed tooling for a monitoring solution of a decentralized and distributed application landscape.

Microservices give us many options. We can pick different technologies, mix synchronous and asynchronous integration techniques or embrace different deployment patterns. But they also give us different options in how we think about securing our systems. Done right, and microservices can increase the security of your vital data and processes. Done wrong, and you can increase the surface area of attack. This talk will discuss the importance of defence in depth, discussing the many different ways in which you can secure your fine-grained, distributed architectures.

At SoundCloud we managed to break away from the monolith while delivering key business features. Our journey towards a microservices architecture has not been a straightforward one. We experimented a lot to reach the set of tools and technologies that we use today. We changed how we build our applications. We introduced specific apis for our mobile and web clients. We call them BFFs (backend for the frontend). They became the central piece of SoundCloud’s architecture. We rethought how we monitor our services. We created a service registry for knowledge sharing. While making all these changes, we benefited from the learnings of our peer companies. This talk will share our learnings from this journey: what worked for us and what we moved away from.

“Circuit Breakers, Stranglers, Metrics, Stressors, Simian Armies, small (but not too small) services, integration styles, composite UIs, API design, API documentation, API evolution, Reactive Streams, Events, Event Sourcing, Logging, Automated deployment, blue/green switchover, flexible infrastructure, bulkheads, PaaS, Cloud, DevOps Culture, Antifragility …” the list really does go on! Whoever said adopting microservices was easy never saw the sheer list of things to be considered! But the benefits are worth it… Microservices offer an architectural style that is flexible enough to become the de-facto approach for future enterprise software systems, but the individual journeys, and pitfalls vary dramatically from context to context. Russ will share several real-world technical journeys, the tradeoffs that have been made, the tools that had to be invented and, finally, how to adopt your own effective “Microservices UX”, the best and most effective user experience for those having to plan, architect, develop, deploy and maintain microservices within their own systems.

Without any doubt Eric Evans' book "Domain Driven Design" is being considered as a "must have read" among many IT specialists from various domains. With the emergence of Microservices Domain Driven Design has become more relevant then ever. This talk explains how the patterns and concepts of Domain Driven Design relate to Microservice architectures. In addition to that I will show off how Domain Driven Design will help you to structure and model your Microservices in terms of granularity, business context and interface design (just to name a few). 

1) Micropuzzling: Implications of slicing web frontends according to Microservices. (Tobias Deekens)

Microservices are an accepted paradigm for backend software systems and show undeniable benefits. However, web applications - especially Single Page Applications - are often developed and deployed as a monolith bearing challenges regarding extensibility and maintainability. This session illustrates practicable patterns for modular web applications from development to deployment. Topics covered will briefly focus on recent evolutions enabling modular web applications and how an split up application can be efficiently served to a browsers. Therefore, the talk will also make brief references to current frameworks to extract their patterns dealing with reusability and compressibility while also pointing out how underlying developments in web standards help lay foundations to fight commonly faced issues. Solutions proposed will also make short references to existing systems developed at E-POST Development GmbH.

2) Automatic Test generation for REST-APIs (Bodo Junglas)

One of the main problems of coordinating multiple development teams in a micro-service architecture relies in API documentation and contract testing:One team has to inform other teams about its APIs and depends on other teams to be conform to the APIs they provide.While there are several de-facto standards for documentation of REST-APIs, creating a reliable in test-infrastructure in regard to conformance and downward-compatible changes is still a challenge.We will discuss an approach for contract testing based on Scala-Check and Swagger.

3) A Microservices approach for Cloud Manufacturing (German Terrazas)

The future of industrial manufacturing increasingly depends on maintaining and expanding a resilient and sustainable sector based on sophisticated technologies, relevant knowledge and skill bases, and infrastructure that has the ability to produce a high variety of complex products faster, better and more cheaply, thus fostering the link across multiple geographically distributed manufacturers, suppliers and customers. In this talk we present our ongoing work in Cloud Manufacturing defined as an approach for enabling ubiquitous, convenient, on-demand network access to a shared pool of physical manufacturing resources and capabilities that can be rapidly provisioned and released with minimal management effort or service provider interaction. Although manufacturing networks and virtual enterprise models already exist, native cloud architectures such as microservices play a key role to facilitate an optimal, efficient and fault tolerant modelling and implementation of such concept. In particular, we aim to show how our multi-layered Cloud Manufacturing conceptual architecture could be effectively delivered in terms of loosely coupled polyglot services, asynchronous communication and reactive modelling in order to virtualise, search, match, configure and combine a mixture of entities, roles, processes and information of different sorts of granularity from scratch to satisfy specific real world production requirements.

How is the cloud built? We will go into detail how we write microservices that run the cloud at scale. With tens of the thousands of customers, and 10+ datacenters. We will talk about how we write, monitor and deploy the microservices that run the cloud you use. 
----- 
Digital ocean is one of the largest cloud providers on the planet with 10 different datacenters and tens of the thousands of customers. We will talk about how we use microservices to power our cloud.
First we will talk about how we using a combination of GO, Ruby and Perl to build microservices. The trade offs of different rpcs protocols such as GRPC and http/JSON.
Second we will dive into how we manage service discovery with Consul on thousands of nodes. 
Third we will talk about how we monitor health and performance of the cloud. We will go into how you should build metrics into your microservices. How we use structured logging into kibana. 
Last we will talk about different deployment strategies we have used, including some on bare metal for hypervisors. Some at virtual machines. Lastly our more modern pieces that run on Docker and Mesos. We will go through how we tried all this different techniques to find the right one for each service.

With the continuing success of the Docker engine, containers are increasingly moving from build chains into production environments. So it's high time to assess the current state of security of one’s container environment. Luckily, the Docker eco system is beginning to provide more and more tools to deploy security measures – some of the them being already active per default. At the same time, several pitfalls exist that could lead to a vulnerable environment.

The talk aims to present a security model covering multiple layers from building images, to the Docker host, and daemon, and up to containers at runtime while focusing on the knobs and levers for building a secure system.