Microservices are still the rage—and for good reason. However, like any other emerging architecture, they’re not a silver bullet and anyone who adopts this architecture will need to learn and identify new patterns, patterns you didn’t need to know about in a monolithic world. This session discusses when to make the switch to a microservice architecture and the patterns Atlassian has identified in building microservices. They include patterns in code organization, configuration management, deployment, resilience, and decomposition. After this session, you will be able to identify whether you should give microservice architecture a try and, if so, you will have a toolbox full of patterns to apply in your own situation.

1 favorite thumb_down thumb_up 0 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist

Outline/structure of the Session

We've started the microservice journey at Atlassian a few years ago. Looking back there were a lot of decision to be made that were hard at that point in time. With the knowledge built up over time, these decisions look trivial know. Hence I'm quite passionate sharing these learning to kickstart anyone in the audience who is about to go on this journey or is in the midst of it.

This session will kick off by setting the stage on how microservices are used at Atlassian. I will look at the main problems that Atlassian was having building products with large engineering teams and big old code bases. The next step involves the promises a microservice architecture. This provides the foundation of the talk, as we will come back at these promises whilst discussing the five important "things" or patterns.

The first pattern to discuss are the basics of microservices that will be covered fairly quickly. Think of the 12 factor app, concepts such as "treat them as cattle not pets" and the blueprint Atlassian uses for every micro service build.

Once the basics are covered I will be discussing deployments which are a critical element when moving into a microservice architecture. I will cover deployment smells, the need for control within the engineering team and I will dig a little deeper on how Atlassian solved this problem by building a declarative deployment platform on top of AWS.

Next up is testing which dramatically changes in a microservice architecture. "Spinning up the world" doesn't work anymore or won't scale at least. Therefore I would like to discuss alternative patterns like introducing mocks that can run either in- or out of process and how to verify the validity of these mocks via patterns like Contract Testing. Or choose from having a stable API in combination with a CTK (Compatibility Test Kit) or simply rely on production monitoring.

After this, I will cover security and will briefly discuss the available web standards like OAuth and explain why these don't work for service to service authentication. I will then show the service to service authentication mechanism used by Atlassian and explain how the audience can use it as well as this is open sourced.

The talk will end by talking operations by briefly going into the increased chance of failure that is part moving into a microservice architecture. Once this is the defined I will continue with various patterns that can be used to overcome this. Think of patterns like "You Build it You run it" and the need for circuit breakers and request tracing.

Learning Outcome

The audience should leave the talk with a set of patterns they could immediately within their own setting and should avoid learning it the hard way.

Target Audience

Engineers, Engineering Managers, Architects

schedule Submitted 3 weeks ago

Comments Subscribe to Comments

comment Comment on this Proposal