The Agile movement shifted the relationship between clients and developers in a profound way. In waterfall processes, clients specified large amounts of functionality, then nervously faded into the background until the fateful day-of-delivery. With Agile, developers strove to engage with clients continuously, and delivered much more frequently against their needs. A new trust was established. At the Forward Internet Group in London, we are implementing a second major shift between clients and developers. The trust of the clients in developers evolves into a broader trust of the developers to deliver business value without resorting to a series of well-defined stories. In essence, the business has empowered the developers to do what they think is right for the business. This model, popularized by Facebook, has several labels, but the one we prefer for our flavor is Programmer Anarchy.

Hands-on development of asynchronous micro-services using a bus architecture.

While “micro-services” is becoming a heavily over-worked term, it has been interpreted many ways. In this hands-on workshop, we will explore a particular style, tiny asynchronous services, that was the core of one of the most successful implementations. Given an animated specification of flow, we will embark on delivering the proposed services, wrestling with the issues common to this new paradigm. Participants have a choice of languages, with new starting code in Java, C#, and Ruby. At the end of the workshop, we will discuss MicroServices challenges and organizations that are optimized for such architectures.

IoT, the prevalence of specialized interconnected devices, has invaded business and home. The myriad of devices, hubs, and APIs has created a Tower of Babel that makes the Android phone scene seem mild. Such devices are inherently less network ­reliable than previous products, primarily due to the casual attachment (convenient outlets). Add to this heterogeneous soup the security exposure that has already been exploited in DDoS attacks, and you have an environment begging for technical solutions.

We propose Asynchronous MicroServices as a solution. Borrowing a page from historical J2ME thinking and more recent implementations using IFTTT, we introduce small bridging MicroServices for the various devices. Further, also consistent with MicroServices, we keep these services very simple: They broadcast device status to an event bus, or listen for action commands to relay to the devices from the same bus. Interaction among the various IoT devices is delegated to yet another set of MicroServices.

One exemplary composite application would accept signals from motion detectors to turn on appropriate lights, or alternatively alerting the owner of unauthorized intrusion. Using the same motion detectors, lights can be dimmed and eventually turned off. Room temperatures and even audio/video gear could be adjusted as well. Using Asynchronous MicroServices, we can also set up controlled access from the outside world, rather than exposing each device with its own vulnerabilities.

Finally, we wrap up talking about the challenges of implementing this in my own flat using Hue lights, Amazon Alexa, and 4th generation Apple TV. We run these MicroServices in local containers attached to the same home network. Docker support of ARM devices enables low-cost redundancy as well.

RESERVE YOUR SEAT NOW

While “micro-services” is becoming a heavily over-worked term, it has been interpreted many ways. In this hands-on workshop we will explore a particular style, tiny asynchronous services, that was the core of one of the most successful implementations.

WHAT WILL I LEARN

Given an animated specification of flow, we will embark on delivering the proposed services, wrestling with the issues common to this new paradigm. Participants have a choice of languages, with new starting code in Java, C#, and Ruby. At the end of the workshop, we will discuss MicroServices challenges and organizations that are optimized for such architectures.

RESERVE YOUR SEAT NOW

IoT, the prevalence of specialized interconnected devices, has invaded business and home. The myriad of devices, hubs, and APIs has created a Tower of Babel that makes the Android phone scene seem mild. Such devices are inherently less network ­reliable than previous products, primarily due to the casual attachment (convenient outlets). Add to this heterogeneous soup the security exposure that has already been exploited in DDoS attacks, and you have an environment begging for technical solutions.

We propose Asynchronous MicroServices as a solution. Borrowing a page from historical J2ME thinking and more recent implementations using IFTTT, we introduce small bridging MicroServices for the various devices. Further, also consistent with MicroServices, we keep these services very simple: They broadcast device status to an event bus, or listen for action commands to relay to the devices from the same bus. Interaction among the various IoT devices is delegated to yet another set of MicroServices.

One exemplary composite application would accept signals from motion detectors to turn on appropriate lights, or alternatively alerting the owner of unauthorized intrusion. Using the same motion detectors, lights can be dimmed and eventually turned off. Room temperatures and even audio/video gear could be adjusted as well. Using Asynchronous MicroServices, we can also set up controlled access from the outside world, rather than exposing each device with its own vulnerabilities.

Finally we wrap up talking about the challenges of implementing this in my own flat using Hue lights, Amazon Alexa, and 4th generation Apple TV. We run these MicroServices in local containers attached to the same home network. Docker support of ARM devices enables low cost redundancy as well.

IoT, the prevalence of specialized interconnected devices, has invaded business and home. The myriad of devices, hubs, and APIs has created a Tower of Babel that makes the Android phone scene seem mild. Such devices are inherently less network ­reliable than previous products, primarily due to the casual attachment (convenient outlets). Add to this heterogeneous soup the security exposure that has already been exploited in DDoS attacks, and you have an environment begging for technical solutions.

We propose Asynchronous MicroServices as a solution. Borrowing a page from historical J2ME thinking and more recent implementations using IFTTT, we introduce small bridging MicroServices for the various devices. Further, also consistent with MicroServices, we keep these services very simple: They broadcast device status to an event bus, or listen for action commands to relay to the devices from the same bus. Interaction among the various IoT devices is delegated to yet another set of MicroServices.

One exemplary composite application would accept signals from motion detectors to turn on appropriate lights, or alternatively alerting the owner of unauthorized intrusion. Using the same motion detectors, lights can be dimmed and eventually turned off. Room temperatures and even audio/video gear could be adjusted as well. Using Asynchronous MicroServices, we can also set up controlled access from the outside world, rather than exposing each device with its own vulnerabilities.

Finally we wrap up talking about the challenges of implementing this in my own flat using Hue lights, Amazon Alexa, and 4th generation Apple TV. We run these MicroServices in local containers attached to the same home network. Docker support of ARM devices enables low cost redundancy as well.

MicroService Architectures has debuted on the ThoughtWorks Technology Radar as the first technology they address, and with strong recommendations to immediately experiment. In this talk, we discuss the challenges we have faced at three different companies in implementing MicroServices (successfully!), and the different ways we addressed the challenges.

A common theme runs through conferences, whether focused on MicroServices, DevOps, Lean Startup, or a myriad of other popular topics: Enabling an organization to Go Faster . I explore the need to go faster (which is hardly new), and three areas inhibitors arise: Technology choices, staid business Processes, and traditional Organization structures and roles. For each, I cite personal experiences in overcoming each.

It is one thing to talk about MicroServices. It is another altogether to have to build them.

After a brief introduction of MicroService principles, we will watch an animation of a MicroService environment. We will start with a pre-built skeleton microservice environment (message bus plus a couple of RESTful services running against it). We will then design and implement additional services to broaden the overall functionality. These additional services can be written in any language that will run on the participants laptop. While pairing is strongly encouraged, it is not required.

In the final stage, different pairs will implement different services, yet they will all run together implementing the animation.

We wrap up with the participants making observations on what they learned (and how it may be different from MicroServices they are currently implementing, if any).