Micro CPH is a 2-day single track conference taking place in Copenhagen on May 11-12 2020. Join us for inspiring talks about microservices, distributed and event-driven architecture, and get insights into the operational side of developing, running, deploying and testing microservices.

Buy tickets
image description image description image description

speakers

Christin Gorman

Kodemaker

Sam Newman

Independent consultant

Mike Amundsen

Co-author of the book "Microservice Architecture"

Daniel Bryant

datawire.io

Nicky Wrightson

Skyscanner

Gojko Adzic

Neuri Consulting LLP

Stefan Tilkov

InnoQ

Bernd Ruecker

Camunda

Christian Horsdal

Independent Consultant

Mads Hartmann

Glitch

Luke Blaney

Financial Times

Gustaf Nilsson Kotte

Ikea Digital

Szymon Pobiega

Particular Software

Troels Damgaard

Edlund A/S

ChristinGorman

Kodemaker

Christin has been writing software for 19 years and is known for her energetic, engaging and entertaining presentations.

"Our architecture is a mess!" Are you sure?

Session

Have you seen those three dimensional modern art installations that look like a complete mess until you see it from the correct angle and a nice picture emerges? Software can be like that. What might look like a mess from one angle, is beautiful from a different one.
“We’ve got too many applications!”, “Just look at this architecture diagram! Lines all over the place”, “It’s a mess!”
These are common complaints from architects and developers alike in large organisations with software that performs all sorts of different tasks. But are we looking at the diagram from the correct angle?

I will present some examples and discuss how to reason about large software portfolios, go through which parts go together and which ones can or should be decoupled, and help identify that angle that gives us the best view of our systems.

SamNewman

Independent consultant

Sam Newman is an independent consultant specialising in helping people ship software fast. Sam has worked extensively with the cloud, continuous delivery, and microservices and is especially preoccupied with understanding how to more easily deploy working software into production. For the last few years, he has been focusing in the area of microservice architectures. He has worked with a variety of companies in multiple domains around the world, often with one foot in the developer world and another in the IT operations space. Previously, he spent over a decade at ThoughtWorks and then left to join a startup, before setting up his own company. Sam speaks frequently at conferences and is the author of Building Microservices and Monolith to Microservices (O’Reilly).

Here, there and back again

Keynote

Microservices have become - rightly or wrongly - one of the dominant styles of software architecture in recent years. But rather than being something brand new, microservices are in fact built upon foundations of technology and experience from much earlier work.
In this talk, I will take you through a short history of the work that helped lead us to microservices, to see what lessons we can learn from the past. From structured programming in the 1970s to cloud and containers in the 2010s, via agile, DevOps and SOA, there are many ideas we should take from what came before to ensure we don’t repeat too many of the mistakes of the past.
By understanding some of the fundamental concepts that microservices build upon, you’ll be better able to understand where microservices fit, and how to get the most out of them.

MikeAmundsen

Co-author of the book "Microservice Architecture"

<span">An internationally known author and speaker, Mike Amundsen travels the world discussing network architecture, Web development, and the intersection of technology and society. He works with companies large and small to help them capitalize on the opportunities provided by APIs, Microservices, and Digital Transformation. 

Amundsen has authored numerous books and papers. He contributed to the O'Reilly book, "Continuous API Management" (2018).  His "RESTful Web Clients", was published by O'Reilly in February 2017 and he co-authored "Microservice Architecture" (June 2016). His latest book -- "Design and Build Great APIs" -- for Pragmatic Publishing is scheduled for release in early 2020.

Navigating the World of Self-Driving APIs

Session

To realize the promise of easy self-service integration with APIs, we need to move past the system of bespoke API providers and single-use API consumers to an ecosystem where API-based applications can act as goal-seeking "self-driving" applications. We need an implementation approach that makes it possible for API consumers to solve their own problems at runtime by selecting, connecting to, and interacting with available services -- even when services move and change over time.

This ability to operate autonomously has been a part of the plan for self-driving cars for close to a decade. And we can learn from advances in the automotive field and apply the same principles to the virtual world of the API ecosystem.  

Using existing protocols, formats, and technologies, this talk shows how we can implement autonomous API platforms today and reduce the time it takes to bring solutions to market and increase the re-usability and stability of existing services on the Open Web.

The world of self-driving APIs is closer than we think and the time to take advantage of this opportunity is now.

DanielBryant

datawire.io

Independent Tech Consultant & Product Architect at Datawire

Daniel Bryant works as an Independent Technical Consultant and Product Architect at Datawire. His technical expertise focuses on ‘DevOps’ tooling, cloud/container platforms, and microservice implementations. Daniel is also a Java Champion, contributes to several open source projects, writes for InfoQ, O’Reilly, and TheNewStack, and regularly presents at international conferences such as OSCON, QCon and JavaOne.

The Future of Cloud Native API Gateways: Declarative, Self-Service and Multi-Protocol

Session

The introduction of microservices, Kubernetes, and cloud technology has provided many benefits for developers. However, the age-old problem of getting user traffic routed correctly to the API of your backend applications can still be an issue, and may be complicated with the adoption of cloud native approaches: applications are now composed of multiple (micro)services that are built and released by independent teams; the underlying infrastructure is dynamically changing; services support multiple protocols, from HTTP/JSON to WebSockets and gRPC, and more; and many API endpoints require custom configuration of cross-cutting concerns, such as authn/z, rate limiting, and retry policies.

A cloud native API gateway is on the critical path of all requests, and also on the critical path for the workflow of any developer that is releasing functionality. Join this session to learn about the underlying technology and the required changes in engineering workflows. Key takeaways will include:

- A brief overview of the evolution of API gateways over the past ten years, and how the original problems being solved have shifted in relation to cloud native technologies and workflow
- Two important challenges when using an API gateway within Kubernetes: scaling the developer workflow; and supporting multiple architecture styles and protocols
- Strategies for exposing Kubernetes services and APIs at the edge of your system
- Insight into the (potential) future of cloud native API gateways

NickyWrightson

Skyscanner

Nicky is a principal engineer working at Skyscanner and formerly of the Financial Times and has been leading teams for more than 15 years, across a wide range of industries: travel, banking, media and telecommunications. She passionately drives forward cloud native architectures and approaches that allow engineers to deliver deliver business value quickly whilst also reducing the support overhead needed for complex distributed systems.

Living without pre-production environments

Session

Historically when we developed large monolithic applications we had several ‘lower’ environments such as dev, test, staging, pre-prod for verifying different stages of our development life cycle. These were particularly used for manual testing - integration testing, gatekeeping, acceptance testing. However as we are moving to increasingly more distributed, complex and larger systems we have sought tools and processes to enable us to move quicker. We have more automation in our testing, we have more automation in our deployment and we are creating services that are loosely coupled and independently deployable. With this all the tooling and approaches now available to us, should we still be spending our time and money on running all these lower environments?

We thought not - At Skyscanner we don’t have lower environments only production. Well actually it is slightly more complicated than that but we will get to that. 

So in this talk Nicky will talk about:

  • Why Skyscanner has chosen to ditch non production environments
  • How Skscanner do this - What we have done to make this working practice possible and how do we maintain quality and confidence
  • When does this approach not work - There are definitely some unsuitable use cases for this approach

GojkoAdzic

Neuri Consulting LLP

Author of Running Serverless, Impact Mapping, Specification by Example and a few more books… Working on MindMup and Claudia.js.

How serverless impacts design

Session

Serverless architectures are becoming mainstream, significantly reducing time to market and operational costs; but to get the most out of this opportunity, applications have to be designed around the constraints of this deployment architecture. This session is a mix of an experience report and looking at future trends, explaining how domain modelling, distilling the core and serverless architectures overlap.

StefanTilkov

InnoQ

Principal Consultant & Conference Tourist

Stefan Tilkov is a co-founder and principal consultant at innoQ. He has been involved in the design of large-scale, distributed systems for more than two decades, using a variety of technologies and tools. He has authored numerous articles and a book (“REST und HTTP”, German), and is a frequent speaker at conferences around the world.

“Good Enough” Architecture

Session

Stefan Tilkov takes a look at some of the ways you can determine whether the development efforts you’re undertaking suffer from too much or too little focus on architecture. You’ll examine a number of real-world examples that are intended to inspire either admiration or terror and try to find some recipes of how you can get more of the former and less of the latter in your own projects. You’ll look at examples for both options and hear anecdotes, with names and details changed to protect the sometimes not completely innocent, and try to extract descriptions of some common positive and negative influences. The goal isn’t to come up with a perfect recipe, but rather with some approaches Stefan has seen actually work in practice.

BerndRuecker

Camunda

Co-Founder and Chief Technologist

Throughout my 15+ years in software development, I have helped automating highly scalable core workflows at global companies including T-Mobile, Lufthansa and Zalando. I have contributed to various open source workflow engines. I am co-founder and developer advocate of Camunda, an open source software company reinventing workflow automation. I co-authored "Real-Life BPMN," a popular book about workflow modeling and automation, now in its fifth edition and available in English, German and Spanish. I regularly speak at conferences and write for various magazines. I am currently focused on new workflow automation paradigms that fit into modern architectures around distributed systems, microservices, domain-driven design, event-driven architecture and reactive systems.

Balancing Choreography and Orchestration

Session

These days, many teams favor loose coupling, isolation and autonomy of services and therefore typically opt for event-driven and reactive architectures, using a communication pattern known as choreography. While choreography is beneficial in some situations, it is far from the holy grail of integration. In some scenarios, it increases coupling, often accidentally and to a dangerous degree. Orchestration is a better choice for some situations, but is often bashed for introducing tight coupling. I will debunk some of these myths and show how orchestration can even reduce coupling in some situations and totally work in an asynchronous, message-driven fashion.

TLDR: Choreography vs. orchestration is NOT about choosing THE right approach. In real life, you need to balance both, so it is about choosing wisely on a case-by-case basis. In order to help you with that, I will walk you through the differences and give you some concrete guidance on decision criteria, backed by examples collected in various real-life projects.

ChristianHorsdal

Independent Consultant

Consultant, author of "Microservices in .NET Core"

Christian Horsdal is an independent consultant with 20 years of experience building many kinds of systems from large scale microservice systems to tiny embedded systems and lots of stuff in between. He is a .NET expert, author of the books "Microservices in .NET Core" and "Instant Nancy Web Development", trainer, and an occasional open source contributor.

Identifying and Scoping Microservices

Session

Microservices are great. Or at least that is what all the buzz says. And they are. If you get them right. That is, if you get boundaries between them and the scope of each one right. If not, microservices are just a distributed mess - which is worse than a monolithic mess. In this talk I will outline how you identifying good candidates for microservices and how you define the scope for each one in a way that optimizes for maintainability in the long run, resilience in production and efficiency of work.

MadsHartmann

Glitch

Site Reliability Engineer at Glitch

Mads works as a Site Reliability Engineer at Glitch. He loves diving head first into production issues, especially the weird ones. When he isn’t rummaging around in production he spends his energy making it easier to understand, and eventually more reliable.

Lightning talk: Journey into Observability

Session

Glitch is a platform that allows anyone to instantly create a web app right from their browser. Each is a full-stack app in its own container.

As Glitch was getting an ever-increasing amount of traffic we were sometimes struggling to keep up; what was previously considered performance edge-cases were now commonplace. A lot of Unknown-Unknowns became Known-Unknowns. About a year ago we started investing in observability tools in the hopes that it would help us maintain a high level of reliability so we could continue to provide a great experience for our users, even as more and more people started to run their apps on Glitch.

In this session, I'll go through Glitch's journey into Observability. I'll cover both the victories as well as the bumps in the road. As we go I’ll share what we might have done differently if we had to do it over, so you can be off to a good start if you want to make a journey into observability.

The attendees should walk away with a clear understanding of what observability is, why they might want to invest in it, and a reasonable plan on how to get there.

LukeBlaney

Financial Times

Principal Engineer, Financial Times

Luke has worked for the Financial Times since 2012 as a Developer and then Platform Architect. Now a Principal Engineer on their Reliability Engineering team, tasked with improving operational resilience and reducing duplication of tech effort across the company.

Monitoring All the Things: Keeping Track of a Mixed Estate

Session

Monitoring all of a team's systems can be tricky when you have a microservice architecture. But what happens when you have many teams, each building systems using totally different technology stacks? Add in decades of legacy systems and a sprinkling of third-party tools and you’ve got plenty of fun in store. Discover how to approach monitoring an estate of many technologies and find out what the Financial Times did to improve visibility across systems built by all its teams.

GustafNilsson Kotte

Ikea Digital

Web Architect at IKEA Digital

Gustaf Nilsson Kotte is the lead of the Web Architecture Group at IKEA Digital and works as a lead engineer in the Frontend Framework team. He has over 10 years professional experience of building web sites, but he wrote his first web page 23 years ago and has been interested in creating things for the web ever since.

Gustaf has a MSc in Computer Engineering from Chalmers University of Technology, with double specialisation in Software Engineering and Computer Languages.

Growing Micro Frontends, Guided by Friction

Session

Four years ago, we started to build the new ikea.com e-commerce website. Today it serves over 2.5 billion visits per year. The website is currently developed by 15-20 frontend teams and built using a Micro Frontends architecture.

We started small, while thinking big. The journey was not a straight line and we have faced a lot of friction along the way. However, this friction can often be a good thing as it guides us in what our next steps should be.

You’ll learn about the basic building blocks of our web architecture such as static files, transclusion and reusable components. I’ll also talk about what I think the future direction could be.

SzymonPobiega

Particular Software

Engineer particularly interested in software

Szymon works an engineer at Particular Software, the makers of NServiceBus. His main areas of expertise are Domain-Driven Design and asynchronous messaging. He is especially interested in the intersection of these two topics -- in the patterns and tools for ensuring all messages are processed exactly once and in the correct order.

In his free time Szymon plays with Lego, building models of real-life off-road vehicles.

Exactly-once processing is easy. But wait! My bill does not match my order

Session

No matter what technology vendors claim, the laws of the universe make exactly-once message delivery impossible. The only options we have are either losing messages (at-most-once) or getting duplicates (at-least-once). Let me suggest which one you should prefer: you don't want to miss that one million dollar order and only figure it out when reading the logs two weeks later.

Join me in a journey to explore various ways of ensuring duplicates are properly detected and handled. In the end, losing and order is surely bad but you don't want to fulfil that million dollar order twice either, do you?

Along the way we'll look at natural idempotence of certain data structures, immutable data and identity-based de-duplication.

TroelsDamgaard

Edlund A/S

Coding architect at Edlund A/S

Proglang researcher turned full-time software developer. Currently architecting at Edlund A/S. I like microservices, DSLs, distributed systems, writing and building stuff.

Lightning talk: Experiences introducing Kafka in our stack

Session

In this talk, I will discuss our learnings, positive and negative, in introducing Kafka into our large, mostly monolithic, .NET based software architecture.

Underway, I'll share details on our initial plans and designs. I'll quickly, however, curve into airing our dirty laundry and tell about false starts and setbacks.

I'll end on a positive note, and share our current state of affairs, and give some pointers for what you should look out for - both technical and less technical.

workshops

Strategic DDD using Bounded Context Canvas

May 13-14 09:00 - 17:00

Design loosely-coupled, domain-aligned sociotechnical systems with the Bounded Context Canvas

One of the biggest challenges of DDD and architecture in general is breaking a large system down into loosely-coupled sub-systems. Using the Bounded Context Canvas you will learn how to decompose large problem domains into cohesive, autonomous, domain-aligned bounded contexts which become the blueprint for your software architecture and your organisation structure.

// Register >>
Nick Tune
Kacper Gunia

Consistent messaging in the cloud

May 13-14 09:00 - 17:00

How to build fault-tolerant distributed systems when throwing away consistency is not an option

Building fault-tolerant distributed systems that maintain full consistency is not an easy thing. What makes it even harder is lack of solid infrastructure foundations like distributed transactions. Forget about them. Learn to build reliable system from unreliable components available in the cloud.

 

// Register >>
Szymon Pobiega
Tomek Masternak

Strategic DDD using Bounded Context Canvas

Design loosely-coupled, domain-aligned sociotechnical systems with the Bounded Context Canvas

Working in the setting of a complex domain, you will learn the essential theory of Strategic DDD and Bounded Contexts, and then put it into practice by modelling the domain as a series of loosely-coupled, highly-cohesive bounded contexts aligned with natural contours in the business domain.

As you model the large domain, you will learn how to make business model-guided modelling choices by identifying the highest value parts of a system - the core domains - as well as generic and supporting capabilities.

You will work iteratively, refining your designs to accommodate key technical details like NFRs and legacy constraints. Finally, you’ll learn how to shape the organisation that will build and deliver the bounded contexts, rounding out your sociotechnical design skills.

On your journey, you will be guided by the Bounded Context Canvas, providing you with a structured process for exploring and identifying bounded contexts and teaching you the essential questions to ask in order to find a good design, and challenge it to find even better ones.

Who Should Attend

Anybody who works in software teams or with software teams will be able to fully participate in this workshop and take away concrete skills they can apply in real working situations. The following is a selection of the types of people who may want to attend:

  • Software Engineers of all levels
  • Architects
  • Testers
  • Product Managers / Owners
  • Business Analysts
  • Delivery Managers
  • Engineering Managers & Directors
  • CTOs

Workshop Details

  • 2 days
  • Dress comfortably, especially footwear, due to the hands-on nature of the workshop (please let us know if you have any questions or concerns. There will be seating available and regular breaks.)
  • Laptops not required - this workshop will not involve any hands-on coding

Nick Tune

Technical Leader

Nick Tune is a product-focused technical leader. He has helped teams in a variety of organisations to achieve continuous delivery and high alignment, including the UK government, Salesforce, and 7digital. He is the co-author of Designing Autonomous Teams and Services (O’Reilly) and Patterns, Principles and Practices of Domain-Driven Design (Wrox), and blogs from ntcoding.co.uk.

Kacper Gunia

Independent Software Architect

Kacper Gunia is and independent Software Architect, Trainer and Consultant with 10 years of experience in the industry. He is passionate about delivering value by creating software that is aligned with the business as well as by enabling teams to be successful & productive with Domain-Driven Design and other methodologies. Kacper worked with clients including Starbucks, World First, Time Inc, GFT Group & Sportradar. In his spare time he runs Domain-Driven Design London meetup.

Consistent messaging in the cloud

How to build fault-tolerant distributed systems when throwing away consistency is not an option

The workshop focuses on building line-of-business, fault-tolerant cloud-based distributed systems. Such systems cannot afford to lose messages (nobody wants their order for Christmas gifts to be lost) nor to get them duplicated (that second Porsche in the driveway - who ordered that?). Such systems were, in the past, built based on the firm ground established by either distributed transactions or large database instances that served also as messaging brokers.

These technologies are either too expensive, too cumbersome or simply not available in the cloud. In this workshop, we will show how one can deal with the consistent messaging problem by de-duplicating messages.

We'll start by asking ourselves a question of why the systems we build need to be distributed. We'll see how duplicating messages is the only way to get components to reliably exchange information. Finally, we'll spend most of our time identifying subtle issues inherent to message processing, devising solutions to these issues and encoding these solutions in reusable patterns.

Join us in the series of ten hands-on exercises interleaved with short lectures after which you'll have a good understanding of most of the things that can go wrong when processing messages and enough knowledge to either build a bullet-and-duplicate-proof message processor or (even better) find a framework that implements one for you.

What will I learn?

For start, you will learn some solid reasons why distributed systems offer a significant advantage over monolithic ones. Once we all agree that distributing components of the system makes sense, we will focus on the communication between these components. You'll learn why message de-duplication is a key part of a successful communication strategy.

Next, you will learn the basic concepts of chaos engineering and how to use it in practice. You will see how a messaging framework can be extended to simulate various types of failures that happen in real production distributed systems. You will use chaos engineering techniques to find flaws in a system even before it gets live.

You will also experience how out-of-order message delivery can wreak havoc in message de-duplication strategies that otherwise seem perfect. Last, but not least, you will learn how to build a practical message de-duplication solution for your distributed system.

Agenda

  • Distributed asynchronous systems - why bother?
  • Idempotent business logic
  • Chaos engineering
  • Simulating failures in the running system
  • Messages are always delivered in order, aren't they?
  • Simulating out-of-order delivery
  • Message identity and identity-based de-duplication
  • Outbox

Structure

The workshop consists of interleaved lectures and practical exercises. The purpose of the exercises is for you to experience the problems first hand while the lectures are there to give you the contextual information and explanation. The exercises are designed to be chained together as each exercise builds upon the the previous one. They are difficult and that's by design. It's not a simple copy-paste thing. The goal is for you to struggle with them at least a bit. But don't worry if you get lost midway through. There is a collection of prepared starting points so if you get stuck in one exercise, you will still be able to start working on the next one.

Prerequisites

The workshop exercises are prepared in C# and .NET however we will not be using advanced features of the language/platform so it should be accessible even for developers that don't have C#/.NET background. The exercise starting points already contain references to all required libraries (NuGet packages) and, whenever possible, we will stick to basic C# constructs.

Below is the list of required software. All three apps are free/have free versions.

Szymon Pobiega

Particular Software

Engineer particularly interested in software

Szymon works an engineer at Particular Software, the makers of NServiceBus. His main areas of expertise are Domain-Driven Design and asynchronous messaging. He is especially interested in the intersection of these two topics -- in the patterns and tools for ensuring all messages are processed exactly once and in the correct order.

In his free time Szymon plays with Lego, building models of real-life off-road vehicles.

Tomek Masternak

Particular Software

Tomek is an engineer passionate about the theory and practice of building message-based distributed systems. Likes to know why they work, fail and what that means in the first place. Writes about building reliable distributed systems at https://exactly-once.github.io/

Here, there and back again

Sam Newman

Identifying and Scoping Microservices

Christian Horsdal

How serverless impacts design

Gojko Adzic

Exactly-once processing is easy. But wait! My bill does not match my order

Szymon Pobiega

Monitoring All the Things: Keeping Track of a Mixed Estate

Luke Blaney

Balancing Choreography and Orchestration

Bernd Ruecker

"Our architecture is a mess!" Are you sure?

Christin Gorman

Navigating the World of Self-Driving APIs

Mike Amundsen

Growing Micro Frontends, Guided by Friction

Gustaf Nilsson Kotte

Living without pre-production environments

Nicky Wrightson

Lightning talk: Journey into Observability

Mads Hartmann

Lightning talk: Experiences introducing Kafka in our stack

Troels Damgaard

The Future of Cloud Native API Gateways: Declarative, Self-Service and Multi-Protocol

Daniel Bryant

“Good Enough” Architecture

Stefan Tilkov

tickets

buy tickets
DKK 2.900
(early bird)

venue

map

We are a team of 5 people all with a developer background who have been organizing various tech meetups and have been part of a number of conferences as speakers and co-organizers for 5+ years.
We have teamed up in order to spice up the Danish tech scene with quality content around software architecture - this time dedicated to the world of microservices and distributed architecture.

code of conduct

X

Conference Code of Conduct

All attendees, speakers, sponsors and volunteers at our conference are required to agree with the following code of conduct. Organisers will enforce this code throughout the event. We expect cooperation from all participants to help ensure a safe environment for everybody.

Need Help?

You have our contact details in the emails we've sent and our twitter handles above.

The Quick Version

Our conference is dedicated to providing a harassment-free conference experience for everyone, regardless of gender, gender identity and expression, age, sexual orientation, disability, physical appearance, body size, race, ethnicity, religion (or lack thereof), or technology choices. We do not tolerate harassment of conference participants in any form. Sexual language and imagery is not appropriate for any conference venue, including talks, workshops, parties, Twitter and other online media. Conference participants violating these rules may be sanctioned or expelled from the conference without a refund at the discretion of the conference organisers.

The Less Quick Version

Harassment includes offensive verbal comments related to gender, gender identity and expression, age, sexual orientation, disability, physical appearance, body size, race, ethnicity, religion, technology choices, sexual images in public spaces, deliberate intimidation, stalking, following, harassing photography or recording, sustained disruption of talks or other events, inappropriate physical contact, and unwelcome sexual attention.

Participants asked to stop any harassing behavior are expected to comply immediately.

Sponsors are also subject to the anti-harassment policy. In particular, sponsors should not use sexualised images, activities, or other material. Booth staff (including volunteers) should not use sexualised clothing/uniforms/costumes, or otherwise create a sexualised environment.

If a participant engages in harassing behavior, the conference organisers may take any action they deem appropriate, including warning the offender or expulsion from the conference with no refund.

If you are being harassed, notice that someone else is being harassed, or have any other concerns, please contact a member of conference staff immediately. Conference staff can be identified as they'll be wearing branded clothing and/or badges.

Conference staff will be happy to help participants contact hotel/venue security or local law enforcement, provide escorts, or otherwise assist those experiencing harassment to feel safe for the duration of the conference. We value your attendance.

We expect participants to follow these rules at conference and workshop venues and conference-related social events.

BEUPDATED

Sign up for our newsletter to stay updated
as speakers are announced and tickets released.
Follow us on twitter: @MicroCPH