Microservices give you many options. You 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.

Audience

Join this talk is you're a developer, an architect, a technical leader, an operations engineer and if you're interested in the design and architecture of services and components.

What You Will Learn

You should come away with a working framework for thinking about AppSec, and also understand how microservices can help (or hinder) building a secure system.

Kafka has become the de facto platform for reliable and scalable distribution of high-volumes of data. However, as a developer, it can be challenging to figure out the best architecture and consumption patterns for interacting with Kafka while delivering quality of service such as high availability and delivery guarantees. It can also be difficult to understand the various streaming patterns and messaging topologies available in Kafka.

In this talk, Jaakko will share with you the patterns the team has successfully employed in production and provide the tools and guidelines for other developers to choose the most appropriate fit for given data processing problem. The key points for the presentation are: patterns for building reactive data pipelines, high availability and message delivery guarantees, clustering of application consumers, topic partition topology, offset commit patterns, performance benchmarks, and custom reactive, asynchronous, non-blocking Kafka driver.

Work takes time to flow through an organization and ultimately be deployed to production where it captures value. It’s critical to reduce time-to-production. Software - for many organizations and industries - is a competitive advantage.

Organizations break their larger software ambitions into smaller, independently deployable, feature -centric batches of work - microservices. In order to reduce the round-trip between stations of work, organizations collapse or consolidate as much of them as possible and automate the rest; developers and operations beget “devops,” cloud-based services and platforms (like Cloud Foundry) automate operations work and break down the need for ITIL tickets and change management boards.

But velocity, for velocity’s sake, is dangerous. Microservices invite architectural complexity that few are prepared to address. In this talk, you'll learn how high performance organizations like Ticketmaster, Alibaba, and Netflix make short work of that complexity with Spring Boot and Spring Cloud.

But what about when the complexity of the business system isn't simple? What about systems where we need to aggregate and combine services to deliver useful business functions that cut across more than one simple service? Event-driven, push-based message passing is often a fundamentally flawed architecture for complex business problems.

In this talk you will discover a resource-oriented view of microservices. Peter will share the trade offs between push and pull architectures. You will explore what lessons the Web's resource oriented architecture offers for complex composite services. Peter will also share how the choice of data format has a profound influence on the composability of microservice solutions.

In this presentation, you will focus on 3 examples of AWS services (Elastic Beanstalk, Lambda + API Gateway, and ECS is AWS) that can easily deploy and scale with any micro service architecture, written in any language.

Elastic Beanstalk is an AWS service that can supply services like EC2, ELB and etc. This service configures those features for an application in a way that all the user needs to do is deploy the application using the application templates of supported platforms (Go, Java, .NET, Node.js, PHP, Python, Ruby, Docker). This service does all the work for your application.

ECS is AWS container service that allows deploying your containers and manage them with ease, the service supports Docker so you can deploy any type of application as long as it containerised.

The microservice architecture is a powerful way to structure large scale Node.js systems, providing a component model that scales both at the human and system levels. To fully gain the benefits of the microservice architecture, you need to move to a continuous deployment work process. It should be possible for developers to write the code for a new feature in the morning, and deploy it to production in the afternoon. This high-speed development cycle allows you to meet business goals much more effectively.

Continuous deployment brings risks. You can no longer manage those risks in the traditional manner. There is no multi-month release cycle to fall back on. The familiar work categories of development, quality assurance, information security, and operations no longer apply. Instead you must learn to live with the devops approach. But giving developers the keys to the server does not automatically imply less downtime, even if you hand out pagers with the keys, and adopt a "you build it, you run it" philosophy. Even when this approach does work, it is notorious for burning people out. Is there a sustainable set of work practice that reduce the risk of continuous deployment to acceptable levels.

The solution is to take a scientific, engineering based approach, grounded in reality and driven by actual business goals. First, quantify the business objectives, both in terms of the value that you intend to create, and in terms of the cost-benefit of failures. There are always going to be failures, so what's your error budget - how much downtime is acceptable? Second, control the production system by making all changes incremental - you are only ever allowed to add or remove a single microservice instance. Nothing else. Microservice instances are built as immutable artefacts - changes to production are not possible. To change behavior, you must deploy a new instance. This gives you a definitive history of the system. It also gives you a way to measure risk!

Each microservice instance change can be measured. By connecting your quantified business goals to the technical metrics of the live system, you can verify each change. Does it improve the metrics or harm them. If it does harm them, then rollback the change. The rollback is not a major event - it is just the deactive of a single microservice instance. By using immutable microservice instance as the unit of deployment, you enable the use of many risk reduction strategies without needed to build custom implementations. From partial deployment, to canaries, to bifurcated verification, to blue-green deployments, and many others. All of these deployment models are defined as operations on microservice instance activation states. By connecting the state of the system with your business goals, and by operating at speed within a defined error budget, you can fully control the risks of microservice deployment, without need the overhead of traditional release planning.

The structured, yet creative freedom afforded by the technique enables teams to explore challenging concepts. For example, in one project, teams from Cisco represented known problems as “monsters” and outdated technologies as “dinosaurs” using plastic toys. In another project, teams from Rackspace used Visible Architectures as means to rapidly integrate acquired technologies.

In this talk Luke will present an overview of the process, how to document desired changes in a structured manner, and how to augment Visible Architectures with powerful business frameworks that enable architects to "speak the business language" necessary to convert models into realities.

Topics covered include:

Envy - introducing inappropriate intimacy within services by creating a shared domain model, and how many teams deploy and use data stores incorrectly;

Wrath - failing to deal with the inevitable bad things that occur within a distributed system;

Sloth - ignoring the importance of NFRs; and

Lust - embracing the latest and greatest technology without evaluating the impact incurred by these choices.

This is an all-new 2016 version of Daniel's popular 'deadly sins talk' that was recently presented at QCon NY. The talk received 94% highest rating, and was the fifth most attended talk at the conference. Daniel plans to continually improve the presentation based on his learnings and attendee feedback.

In 2012 the system that fed video into iPlayer was a monolith. In the nine months between Jan 2013 and Sept 2013 we replaced it with a new system built on a microservices architecture and running in AWS.

This allowed the BBC to more than double the amount of content available in iPlayer and increase the amount of HD content by 700%.

At the same time it has allowed us to move to a continuous delivery model and our developers can now deploy a component to live in under 15 minutes and perform dozens of live deployments every week.

In 2014 we started serving simulcast content (on-line versions of our TV channels) from this new microservices architecture and during 2015 we added Radio. We now also support Podcasts, Audio and Video Clip Publishing, BBC Store and S4C.

This year we have used the system to serve over 300 hours of live content from the Rio 2016 Olympics and for one event this summer we served over 2 million concurrent users.

However doing microservices in the real world, productively, as system’s evolve is a massive challenge!

In this talk Russ Miles, Lead Engineer at Atomist.com, and Sylvain Hellegouarch, Engineer at Atomist.com, through story and music (!?) will name and shame those challenges and then show how they can be overcome with the new tools coming into the space.

Anne will be talking about the power of orchestration and containers, and how that power will be harnessed to produce Microservice systems that can take the knocks and get back up again.

In this talk Michael will explain how to use test driven development for APIs and even further how TDD can drive an API Design towards a more usable design, and how to build an well-tested ecosystem of microservices. This approach is applicable for different kinds of services (REST APIs, websockets, industrial protocols). Independent from the type of interface we always ran into similar problems when we build an ecosystem of services. We have to deal with dependency, asynchronous behaviours, fallback mechanisms, endpoint versioning and sometimes even shared databases. It's not trivial to apply TDD to these kinds of problems cause you have to think of scenarios. But there are ways of identify these scenarios and to test them.

As an API specialist Michael worked with various clients designing, building, testing, maintaining and even redesigning private and public services. Based on his project experience he developed a practical approach to apply TDD to APIs in microservice ecosystems.

You will explore design patterns which will allow you to utilize these different strategies as a deployment concern without significant changes to the business logic.

You will learn how micro-service architecture can be implemented under low latency constraints of 10 - 100 micro-second latencies, in Java in particular, and how these strategies reduce the impact of serializing data and logging.

Consumer-Driven Contracts testing brings an alternative integration testing approach for distributed systems, relying less on live-like integration environments and more on making interactions explicit and quickly verifiable.

This talk will cover how Newsweaver has made CDCs part of its pipeline with Pact and how it improved collaboration and confidence between teams when designing APIs.

You will explore use cases and an example of a distributed queue based architecture for micro services.

Andrew and John will be demonstrating two different 'frameworks' for microservices in a Big Data architecture (with examples):

1. Kafka Consumers as microservices - image processing

2. Spark Jobs as microservices - clustering algorithms + data visualisation

Andrew and John will also share their experiences of using microservices at Tractable.

In recent years David has worked on this problem in several independent projects, and this talk will draw on his learnings within the topic of authenticating end-users. David will describe, compare and evaluate several authentication options from the perspective of how secure they are and how well they comply with the qualities of a well-designed microservice system. You will leave the talk with suggested evaluation criteria and guidance for implementation based on their use cases.

In this talk, Damien will talk about how him and his team are applying several various patterns to improve deployments of the Heroku platform, and how you can apply them to your own app so you feel confident if deploying a change on a friday.

Andy Czerwinski - From Monolith to Micro – Here be Dragons

Svetlana Galkina - Germs, genes and gRPC: microservices for collaborative research

Michael Brunton-Spall - Security and Microservices

David Morgantini - Leading without Leaders

Robert Shield - Serverless File Based Delivery

Simon Hildrew - Plambda! Running the play framework in AWS Lambda

Daniel Gomez Blanco - Effortless scalable services in AWS with CloudFormation

Dave Gurnell - High Flying, Free and Easy: Functional Microservices with Finch

Alex will explore some of the different patterns of Service Discovery in a microservices architecture, and focus on pros and cons, while also mentioning concrete examples of tools and software available.

Much research and effort has gone into orchestrating distributed components, but how should they actually communicate to give the properties that you want, AP, resilience, antifragility, self healing, graceful degradation?

This is the realm of communication protocols, and this talk introduces the core concepts you need, and shows how to use various protocols and implement new ones using a new Microservices Toolkit from Simplicity Itself and Sky CIS Tech Futures: Muon.

Covering async vs sync, event based systems, transactional behaviour over distribution and far more, this is a dive deep into how modern Microservice systems should be built, and how you can get there.

*How can you support a constantly changing state?

*How can you move streams of data across our microservice network?

*How can you split system state across multiple processes, containers or vm?

Enter Upring. Upring is a library to support application-level sharding of “live” data, it supports node streams, and enables every developer to implement application level sharding. What can you shard? As an example, Upring allows to connect two user with a bidirectional communication (the beloved websocket) across hundreds of machines.

At its core, it is a state discovery system.

Microservices can be implemented in many languages Go, Python, D, Kotlin, Ceylon, C++, Java,… does the choice of programming language have a critical effect on the achitectures of microservices.

The session is about scaling of architectures and at what point there have to be "fault lines" to other architectures and whether this turns out to be seamless or the location of real problems..

In his presentation Daniel will share the history of authentication and authorization at Prezi and talk about what process and design decisions lead us to our current approach, especially to inter-service authentication.

This stream of data allows the Jet team to effectively build metaprograms which operate on the state of the distributed system. For example: monitoring for end-to-end SLAs, checking the status of any single process, powering your Ops platform, and automated integration testing of an entire distributed system.

This talk will share with you what the Jet team has done to build this real time, holistic view of our 700+ microservice architecture, so that they can monitor every single process for completion, validate that every single process is behaving as expected, empower their operations team to investigate and triage long running processes (e.g. catalog management and clean up). The talk will cover the DrOrpheus communication protocol they use to create their distributed process context, the telemetry data collection architecture, and the XRay real time telemetry processing platform which enables them to convert billions of telemetry events per day into many different, but accurate, views of their distributed systems state.

In order to create such an environment, you will need to look at more than just one thing or one area of practice you are doing. You need to take into account almost everything related to your environment and development life cycle. In order to achieve this goal, you will explore the following areas:

• Stateless μService Architecture

• Fallback strategies

• Resiliency

• Continuous delivery practices

• Development approach and practices

Adopting this approach has allowed the Ocado E-commerce team to actively allow 20+ developers each able to continuously push changes all the way through to production in under 40min from the moment the change is committed, without needing to worry about the changes other developers are pushing through and no need to worry about each developer having to coordinate their releases and work with each other.