Universal Modeling Language for Service-Oriented Architectures: Part 1

Over the last 20 years, applications have moved from a monolithic mainframe perspective to a scale out vision. However, during this time the representation of applications hasn’t changed that much. This has led to major inefficiencies in their design.

In the first part of this two part blog, I will explain why Canonical believes that a new modeling language is needed for modern applications. I’ll then show how this belief has influenced us whilst building Juju, our cloud modeling and orchestration solution.

In part two, I’ll apply these high-level concepts discussed to build a modular and scalable sentiment analysis application using Juju with Kafka, ZooKeeper, Storm and Node.js. Finally I’ll show how easy it is to swap out components of this application with comparable technologies using Juju.

Keys of representation

At Canonical, we’ve been talking about application modeling using a service-oriented architecture (SOA) for some time. After I arrived at Canonical I started evangelising expanded this language to include Lambda architectures. Now there is not a single show where we don’t present the topic.

When you tell people that a Lambda architecture is the foundation upon which any big data project is built, they understand it’s important. When you tell them that it’s a very simple idea that says “now = (past until yesterday) + (everything since yesterday)” they can grasp the notions of batch layer and streaming layer and they start to spread the word.

Batch, Streaming, Serve, Lambda may not be the best words to describe fundamental ideas, but they became a de facto standard language anyone can use.

The point is that when one manages to craft a language around a concept then the idea can spread and conquer.

What we mean by universal modeling language

When I came across Juju for the first time I understood it as a tool to model services like Hadoop or Storm and deploy them. When talking about it with customers I stressed Juju’s many benefits including faster proof of concepts, a single representation of dev/staging/prod environments, and pluggability of the ecosystem leading to the appstore model for everyone.

Whilst these are the facts, they lack power for an external listener because they do not give the enough context to position the product against some other technology. It’s important to understand that Juju is not only a software application it’s an entirely new abstraction for the world of cloud applications. It’s a new language for modeling complex, large, scalable workloads. Fortunately, this new language relies on only three concepts:

• Service: something that can be consumed by another service or by an entity external to the Juju environment
• Relation: represents the ability for 2 services to communicate together. They are exposed by a service (to explain how it shall be consumed) on one end, and consumed by the counterpart on the other end
• Unit: the atomic representation of an element of service. It may be a VM, a container, a bare metal server etc.

Why you should care

That’s all very neat, but who cares? I think you should. This new abstraction is so powerful that it solves the main communication problem that persists between:

• Business and Developers
• Devs and Ops
• Segregated teams in large enterprises

Business vs. Developers

In developments teams, business owners care about features and time to market, and developers want to understand how things fit together and deliver quality code. While the former envision, the latter need to get their hands dirty. I have seen and participated in countless meetings where people do agree but they can’t admit they do because they don’t speak the same language.

Developers vs. Operations

Developers and Operations don’t share the same vision of IT infrastructure. Devs want to ship their code as fast as possible to production. Ops care about uptime. Ops want to keep in control so they provide Devs with a development environment so confined that it guarantees uptime but limits freedom. That’s called PaaS. It’s good but sub-optimal.

A common modeling language allows Ops to abstract the infrastructure to developers, while preserving the Devs’ freedom.

Segregated teams

In many large enterprises, one team may use Chef while another prefers Ansible. Does that mean only one configuration management system should be used? It’s certainly an option, but they all have strength and weaknesses.

Adding an abstraction layer in the modeling language reduces the overhead of having many competing technologies. It helps teams collaborate where it matters: at the service level.

Conclusion

One of the many keys to successful projects and teams is speaking a common language. With that in mind, Canonical developed Juju, a universal modeling language for service-oriented architectures, that speaks as much to business owners through a visual representation of apps as to DevOps through an abstraction level convenient to both Dev and Ops.

In the next part of this blog, we’ll see how we can apply these SOA concepts to design a modular and scalable application with Juju, then swap an entire part of the architecture without changing the application behavior nor committing a single line of code.