Microsoft issued me a Mac when they hired me to help people use Linux on Azure. If this sounds like the beginning of a nerdy joke, it’s because we need to question long-held opinions, let go of deeply-cherished stereotypes, and welcome this new era of open collaboration.

Let’s take the 10,000 foot tour of today’s cloud, containers, and orchestration landscape before diving into specifics we can use when making calls on microservices, backing data stores, and app decomposition. We’ll talk public cloud, containers, and k8s from the “Open at Microsoft” perspective!

Coming Soon....

Software security defects come in two categories: bugs in the implementation and flaws in the design. In the commercial marketplace, much more attention has been paid to finding and fixing bugs that has been paid to finding and fixing flaws. That is because automatically identifying bugs is a much easier problem than identifying design flaws. The IEEE Center for Secure Design was founded to address this issue head-on. My presentation will cover the IEEE CSD’s first deliverable by introducing and discussing how to avoid the top ten software security flaws. The content was developed in concert with Twitter, Google, Cigital, HP, Sadosky Foundation of Argentina, George Washington University, Intel/McAfee, RSA, University of Washington, EMC, Harvard University, and Athens University of Economics and Business. During the talk, I will introduce and discuss how to avoid the top ten software security design flaws. It's important, of course, to know that these flaws account for half of the defects commonly encountered in software security. But more important still is learning how to avoid these problems when designing a new system or revisiting an existing system.

Architecture plans in enterprises tend to resemble late-night infomercials. First, you see a person or system that seems incapable of survival—a situation that can be immediately rectified if you just buy into the product. (One popular infomercial shows incompetent people mangling tomatoes transitioning into Ginsu-wielding sous chefs; the architecture pitch starts with hideous complexity then moves to clean orthogonal box diagrams.) Operators are always standing by.

Real architecture never reaches that blissful end state. Something always interrupts the program: businesses change, technology changes, or funding dries up. What would happen if you did reach the end state, anyway? Is IT in the company done? Of course not.

The truth is that there is no end state. We must all learn to build systems that evolve and grow. We need to stop aiming for the end state and understand that change is continuous. We cannot predict the details, but we can learn the general patterns.

Michael Nygard demonstrates how to design and architect systems that admit change—bending and flexing through time. Using a blend of information architecture, technical architecture, and some process change, Michael walks you through examples of rigid systems to show how to transform them into more maneuverable architecture.

This workshop includes both teaching and hands-on design sessions. Design sessions will be paper and whiteboard work in small groups. You’ll work on real problems drawn from a variety of industries. If you’re a developer or architect working with medium to large architectures and building applications in the context of existing systems or transitioning to new systems, this is the tutorial for you.

Microservices sound appealing, but what can we do with those ten-million-line code bases? Shared domain objects, horizontal coupling, and years of boundary erosion have left us with enormous complexity and spiderwebs of coupling. Michael will share techniques at various levels of abstraction, from implementation details to API design and responsibility allocation. There’s no silver bullet that will make it easy to decompose a monolith, but you’ll learn some techniques that have helped and some pitfalls to avoid, all based on Michael's experience with both successful and failed transformations.

In this full-day workshop, you will learn how to create applications that survive the rigors of life in production. Too often, project teams aim to pass QA instead of aiming for success in production. Testing is not enough to prove that your software is ready for continuous availability in the corrosive environment of the Internet. During this workshop, you will receive an understanding of the architecture and design patterns that can produce high availability in distributed, multithreaded systems. You will also learn about the antipatterns that can sabotage your systems availability and capacity.

Effective leadership comes with a large learning curve. In today’s rapidly-evolving business climate, this is more true than ever for seasoned leaders and entrepreneurs alike.

Many leaders rely too heavily on past achievements, practices, and ways of thinking to drive positive business results today, but they often need to unlearn those behaviors before they can take a step forward.

Join executive coach Barry O’Reilly as he breaks down a transformative framework that shows leaders how to rethink their strategies, retool their capabilities, and revitalize their businesses for stronger, longer-lasting success.

Large organizations often struggle to launch innovative products, improve processes or create environments to help their people succeed. A number of factors conspire to obstruct moving fast at scale; competing priorities, siloed thinking, risk averse cultures and an inability to adopt an experimentation mindset all play a part.

Lean Enterprise: How High Performance Organization Innovate At Scale lays out an alternative future vision for organizations with practical principles and patterns to help you move fast at scale—and demonstrate why and how to apply these methodologies throughout your entire organization, rather than with just one department or team.

Smart enterprises constantly evolve their system of work, from governance and financial management to technical architecture and organizational design in the pursuit of radically improved performance. Adopting Lean Enterprise is challenging, will take time and commitment, but is vital to harness the forces that can accelerating the rate of innovation in your organization.

The microservice architecture functionally decomposes an application into a set of services. Each service has its own private database that’s only accessible indirectly through the services API. Consequently, implementing queries and transactions that span multiple services is challenging. In this presentation, you will learn how to solve these distributed data management challenges using asynchronous messaging. I describe how to implement transactions using sagas, which are sequences of local transactions, coordinated using messages. You will learn how to implement queries using Command Query Responsibility Segregation (CQRS), which uses events to maintain replicas. I describe how to use event sourcing, which is an event-centric approach to business logic and persistence, in a microservice architecture.

Enterprises need to deliver better software faster. It’s no longer sufficient to release quarterly or even monthly. Instead, organizations must use methods, such as DevOps, to frequently deploy changes into production, perhaps as often as multiple times per day. One obstacle, however, to DevOps-style development is that organizations are often mired in monolithic hell. Key business applications are large, complex, unwieldy monoliths, and so it’s impossible to rapidly and safely deploy changes.

The solution is to adopt the microservice architecture, which is an architectural style that has the testability and deployability necessary for DevOps. In this workshop, you will, through a combination of lectures and discussions, learn how to use the microservice architecture to develop your applications. We will describe how to solve some of the key obstacles you will face including distributed data management. You will learn about strategies for refactoring a monolith to a microservice architecture.

When engineering teams take on a new project, they often optimize for performance, availability, or fault tolerance. More experienced teams can optimize for these properties simultaneously. Now add an additional property: feature velocity. Mental models of architecture can help you understand the tension between these engineering properties. For example, understanding the distinction between accidental complexity and essential complexity can help you decide whether to invest engineering effort into simplifying your stack or expanding the surface area of functional output. Chaos Engineering was born within this conflict between feature velocity and increasing complexity. Rather than simplify, Chaos Engineering provides a mechanism for you to embrace the complexity and ride it like a familiar wave, maintaining our business priorities while dialing up feature velocity.

A Cloud Guru built one of the largest platforms using serverless technologies like AWS Lambda and API Gateway (we don’t run a single server, anywhere). It has been an incredible journey and we learnt a lot of lessons scaling our platform to 650,000+ users.

In this session we’ll share notes from our experience including:

• What our serverless system looks like 2 years in (inc. key metrics, architecture, and cost)
• Our serverless security posture
• Important design patterns and architectures
• Common serverless mistakes and how to avoid them

We will dive in to the design of our platform and share interesting data, go through key patterns and architectures, and discuss what it actually takes to build a scalable, reliable and high-performing cloud-native serverless systems today. This talk will focus on AWS but many of the principles and concepts can be carried across to Microsoft Azure and Google
Cloud Platform.

In the global marketplace that transfers knowledge at the speed of light, we have a massive time delay and that is modern transportation methods. The hyperloop is the first new mode of transport to be created in over 100 years. The motivation is to connect people, reduce congestion, and protect our planet by eliminating CO2 emissions from terrestrial transport. The hyperloop can best be described as space travel on the ground - a magnetically levitating, electromagnetically propelled, passenger vehicle in a vacuum tube. With the elimination of aerodynamic drag and surface friction, power consumption plummets, speeds can reach 700 mph, and waste and cost are minimized. With the use of autonomy the service is on demand and delays become a thing of the past. Dr. Sengupta will discuss how space-age tech coupled to the VC funded innovation environment are enabling the revolution in green transportation from suborbital rocket flights, to electric airplanes, to space travel on the ground with the hyperloop.

The most complicated state in an application is time. Like cooking a bag of microwave popcorn, modern web applications desperately try to keep up with their state through an orchestrated chaos of asynchronous operations popping off in indeterminate cadence. No question, coordinating all this concurrency is hard.

But there's a pitfall at the heart of asynchrony that stays mostly unaddressed.

When an operation doesn't finish right away, synchronously, it's possible the operation may never finish. Or, it may be destined to finish eventually, but a second operation may be raised which means we no longer care about the first. Whatever the case, we need to be able to cancel it. This critical check ultimately protects users from the vagaries of unpredictable systems.

Cancellation should be core to our async programming; no asynchrony should run without it. Too often, such handling is just a corner case exception. Without a cancellation strategy, your applications are incomplete at best.

We'll discuss use-cases for async cancellation and various approaches to managing them.

"A monad is just a monoid in the category of endofunctors".

That fact holds everything you need to know about functional programming (FP), right!? If that sentence is a jumble of confusing words to you, you're not alone.

FP is one of the most powerful programming concepts ever conceived, but it's mired in mountains of terminology and notation and often taught from the top-down. Think about it: it's much easier to think about climbing the mountain once you're already on the top and can see back down. But right now, you're standing at the base of the mountain, ready and eager to climb but all you have is a collection of fancy climbing gear and no clue how to use it to begin the climb.

This workshop is your primer on how to use this climbing gear to get started up the mountain. Most of the core concepts of FP are actually very intuitive and straightforward, when presented from the ground up without confusing terms or symbolic notations. Functional-light is a look at FP that helps you start the climb, not a lecture on why the climb should be easier than you think it is.

We'll look at: function parameters, side effects/purity, composition, immutability, closure, recursion, list operations, and more!

If you're ready to start using FP concepts intuitively and pragmatically to improve your code, and not just hearing confusing terms, this workshop is for you.

Have you ever had a gut feeling a project is about to go off course but no way to validate (or invalidate) that feeling? Has your team ever been burned by an inaccurate estimate or unreasonable expectation? Have you ever wished you could peer a bit into the future?

Navigating the uncertainty of knowledge work is often difficult and uncomfortable. During this session, you’ll learn new ways to visualize your team’s reliability and variability of delivery using the data you already collect. Instead of relying entirely on your gut or laboring over estimates, you’ll learn to predict outcomes and describe their likelihood. While this session won’t teach you to eliminate uncertainty or allow you to see the future, it will provide you with tools to explore and chart a reasonable course through the inherent ambiguity of knowledge work.

This is a workshop with two agendas. The first is to get you up to speed with the Elixir language and the tooling that surrounds it. We'll see why companies around the world are switching to Elixir (and it's not just for the fantastic Phoenix web framework). And we'll do this by writing code: lots of code. By the end of the day you'll have a multi-user, real-time collaborative app up and running.

But there's a second, secret agenda. I want to introduce you to a different way of thinking about programming: state, objects, functions, concurrency: it's all up for grabs. I'm betting that the day after the workshop you'll find yourself writing code differently. Your code will have less coupling, and it will be easier to change. And it doesn't matter what language you're using.

This is a workshop for programmers: I'll run it as fast as you want, and I won't be shy when it comes from giving my personal (and often controversial) opinions.

We're a generation of programmers who grew up with object orientation and imperative programming. When we transition to languages such as Elixir (and even some modern idioms in JavaScript), some of our old reflexes are no longer appropriate. Others are deeply useful, but in different and surprising ways. So, as we work towards the ideal of "programming by transforming", we mustn't forget to transform our thinking, too.

(ps: reducers are objects...)

Container technologies such as Docker are rapidly becoming the de-facto way to deploy cloud applications, and Java is committed to being a good container citizen. This talk will cover some of the new tools and techniques for reducing container size (jlink, Alpine/musl support), for improving startup time and sharing of data between JVMs (AppCDS and ahead-of-time compilation), and the recent work that has gone into interacting with container resource limitations.

When we think of modern data processing, we often think of batch-oriented ecosystems like Hadoop, including processing engines like Spark. However, the sooner we can extract useful information from our data, the better, which is driving an evolution towards stream processing or “fast data”. Many of the legacy tools, including Spark, provide various levels of support for stream processing, but deeper architectural changes are emerging.

Then we’ll work through code examples that use Akka Streams and Kafka Streams with Kafka to implement a machine-learning example where a machine learning model is updated periodically to simulate the problem of periodic retraining and serving of ML models in a streaming context. In particular, if you periodically retrain the model using one tool chain, for example, once a day, how to do you incorporate the updated model into a running pipeline for scoring without restarting the pipeline?

When we think of modern data processing, we often think of batch-oriented ecosystems like Hadoop, including processing engines like Spark. However, the sooner we can extract useful information from our data, the better, which is driving an evolution towards stream processing or “fast data”. Many of the legacy tools, including Spark, provide various levels of support for stream processing, but deeper architectural changes are emerging.

Pre-aggregated metrics and time series form the backbone of many monitoring setups and have many redeeming qualities, but simply aren't sufficient for capturing the many ways things can go wrong in modern or complex systems. Problems inherent in the concepts behind and implementation of pre-aggregated metrics prevent them from being effective for any sort of debugging or diagnostics; we'll talk about why that is, and what techniques we should be leaning on instead.