Service Oriented Architecture (SOA) was the great hope of organizations decades ago when they sought to advance legacy system integration, reduce and bypass layers, and rapidly access the system of record. At the time, the existing solution was point-to-point integration, creating a brittle “spaghetti” middle layer that was hard to manage. This was replaced by SOA, which was later augmented with ESB. This fixed the spaghetti mess by creating an intermediate set of layers, which added complexity to the integration process.

Unfortunately, most IT departments with legacy systems and SOA still struggle to be as agile as needed in this ever-increasing global and digitized world. 

SOA Solved Many Problems, But Not All

Today, upward of 90% of the world’s enterprise applications are monolithic. When they were created, monolithic design was the best approach available. However, as business needs evolved and the demand for greater agility intensified, developers and IT teams are considering breaking free of these monolithic architectures.

SOAs have become a hindrance, not the solution they once were.

The SOA Integration Challenge

The promise of SOA initiatives was extending the reach of core business functions while reducing the internal expenses and complexity that grew alongside monoliths. SOAs achieved these goals by breaking the core functions of a monolith into web services using protocols such as simple object access protocol (SOAP) and eXtensible markup language (XML).

SOAP was built for universal application communications. Because it’s based on XML, SOAs designed with SOAP could, in theory, be used to create an agnostic integration layer. Rather than struggling to piece together various proprietary systems, these protocols would open monoliths on different operating systems so they could work together.

This agnostic integration layer would let system administrators connect pieces of a monolith to an enterprise service bus (ESB) to achieve an agile, plug-and-play SOA. In some cases, this approach succeeded.

A great deal of “legacy SOA” still provides value. In these cases, the value the SOA provides is the behind-the-scenes server-to-server communication that mostly aids developers. When it comes to serving internal and external customers–and their rapidly changing demands–SOA isn’t always up to the task.

To achieve service integration, the ESB must oversee the messages from start to destination. This communication isn’t as simple as the SOA vendors may have promised. Consider an SOA integration within a core banking application. The message must go from the core application on the mainframe to a branch office server. If the business logic states a message is only relevant for one business day, administrators must decide whether to move it to a queue, log or disregard when the day passes. This is a common scenario for core banking applications in an SOA, but how well does it work?

In this example–and others like it–the ESB must know whether a business day has passed to make the right decision about where to send the message. Therefore, the integration requires an algorithm–meaning that ESB cannot simply rely on a universal rule for sending messages between the monolith and external integration.

When administrators introduce new business logic into the monolith integration, it turns what was supposed to be an agnostic service layer into a new application layer, increasing complexity. Instead of simply integrating the monolith into a new digital service, the enterprise ends up with a larger monolith–one that includes the mainframe and all the new integration stacks.

Despite the promises of SOA, the integration problems result in increased maintenance time, greater complexity of code and software and the continued growth (not elimination) of monolithic applications.

The first rule of effective integration is “smart end-points and dumb pipes.” Building logic and layers into the service layer breaks that rule, increases the overall complexity and adds another legacy application to your portfolio.

Bottom line: Trying to optimize the SOA approach will only result in larger monoliths.

Improving SOAs with Microservices

Using microservice architectures helps realize the original promise of SOAs, delivering the benefits of SOAs while removing many disadvantages.

For decades, CIOs have tried to transition away from monoliths by taking traditional approaches to integration, only to find they’ve doubled down on legacy investments. All these integration stacks end up coupled to legacy systems and only result in more work for the IT team–and a less agile organization.

The integration step of SOA was never intended to include business logic. Trying to force business logic into this approach leads to workarounds and extra effort just to achieve a less-than-ideal result.

The key factor is how to incorporate microservices without adverse effects. Luckily, microservices architecture can be forged from SOAs by introducing these new principles:

•   Context Mapping: When replacing an existing SOA, teams must consider the size and scope of the new microservice and apply proper contextual boundaries. For example, SOAs that typically sought broad integration with digital services should be broken down into smaller domains to simplify operation.
•   Shared-Nothing Architecture: Too many SOA integrations create sprawling dependencies that create complexity in the tech stack. Microservices avoid these cross-service dependencies. For those looking to move to microservices from an existing SOA, it’s important to look at the list of dependencies and work toward standalone functionality.

The post Microservices: The Advantages of SOA Without Its Drawbacks appeared first on Artificial Intelligence.

Microservices aren’t a new concept to Java – their forerunner was Service Oriented Architectures (SOA), which could be constructed, among other means, with the assistance of Enterprise JavaBeans (EJBs).

The fundamental concept behind microservices is applications should be broken down into small services that can be arbitrarily scaled independently of one another.

Think Netflix; their entire infrastructure is designed to spawn more web servers or databases as needed, and by all accounts they go pretty far down the code-sharding rabbit hole, obtaining efficiencies the rest of us can only dream about.

The problem with SOA approaches generally, however, was they weren’t very “micro” in their attempts to split up monolithic applications into services. They still retained a relatively large footprint.

The actual line between an SOA and microservices isn’t clearly delineated. At what point is a service micro enough to be a microservice? Some argue that the politics matter more: SOA was typically pushed on developers by magazine-wielding managers. The microservices trend is viewed as a more grassroots movement.

Since an exacting definition of what a microservice is doesn’t really exist, some find it easier to define what a microservice is not.

Fashions change especially in the world of dev, but regardless of the definition boundaries between SOA and microservices, SOA did introduce a generation of developers to the idea of message queuing – a concept that has become important to many of today’s microservices architectures.

Message queues let services to talk among themselves, an important notion if you want your application to actually do something and not choke while waiting for some other aspect of the application service structure to execute.

EJBs were handy because they involved Message Driven Beans (MDBs). MDBs are stateless, service-side components that are transaction and are activated by the EJB container when it receives a message. MDBs helped make EJBs a useful tool for those seeking to use Java to make services that plug into a message-queuing-based microservices architecture.

While EJBs served the needs of the SOA development paradigm just fine – even if the individual services were a bit fat – competing languages kept producing thinner, lighter approaches to microservices than the traditional EJB could deliver.

The pressure was on to make Java more efficient.

One of the more recent responses to this was creation of the Web Profilein Java EE 6. Applications using the Web Profile did not have access to the whole of the Java language and libraries. Only those sections deemed likely to be useful to writing “web-tier” services were included.

For a while, the Web Profile was good. Over time, however, ecosystems changed and pressure grew to support all the modern standards. At the same time the pace of Java version releases slowed. This spurred development of MicroProfile.

MicroProfile defines a Java EE profile that has JAX-RS, JSON-P and CDI. It is not a replacement for Java EE, but rather should be thought of as an extension of it, one whose goal is to keep the environment for microservices evolving to meet emerging standards faster than the language itself is revised. The changes will likely be fed back upstream when the language does experience a versioning event.

Unlike previous attempts to square the microservices circle that focused primarily on service footprint, MicroProfile tries to build a common base that can unite different factions of Java developers. The folks behind MicroProfile are very careful to say they don’t want to create a standard (or set of standards).

MicroProfile is closer to the definition of all the parts of the stack that the majority of Java ecosystem stacks can agree on. An example of this is the inclusion of JSON-P but not JAX-B. This strikes me as a clear statement that JSON-based REST APIs have won, and XML is slated for the dustbin of history. You can still manually include JAX-B (and JAX-P) if you want to play with XML, but the consensus choice is JSON.

Areas where there is still a great deal of contention – such as message queuing – are not defined. The inclusion of CDI does provide the necessary bits to bolt on your message-queuing solution of choice, but you have to make that choice. Use of Wildfly Swarm as the delivery vehicle keeps MicroProfile microservices light.

Finished in September, MicroProfile has the support of some big names that include IBM and Red Hat but it remains to be seen if it will be accepted by the community as a whole. There’s already talk, in the meantime, of extending MicroProfile, with some not happy that technologies they favour aren’t included – or aren’t being included fast enough.

The rest of the ecosystem

Naturally, this being developerland MicroProfile is not alone, and there exists a range of other tools and frameworks for microservics. These include the Akka, Play, and Lagom frameworks that have a strong following, mostly from Scala developers. Lightbend does include Java APIs, and the Play framework in particular has a significant Java developer following as well.

Hashicorp is a powerful name in the microservices world. Even non-developers have heard of some or all of their projects: Consul, Nomad, Packer, Serf, Terraform, Vagrant and Vault all have powerful communities around them. Vagrant in particular is hard to avoid, even for operations staffs. Mulesoft is another popular player.

Docker, Kubernetes, and Apache Mesos, of course, are the much-beloved titans of the operations side of the microservices world. One could reasonably add desired state-configuration tools like Puppet, Chef, Ansible and Salt to the ops side of the microservices list as well.

This is where Dev starts to meet Ops, as desired-state tools are more typically associated with the Ops side of movement than with the very developer-centric microservices movement.

They come together on the new ground of composable infrastructure. Similarly, the ability for infrastructure to be managed by code becomes a factor when buying anything from switches to SANs. To the microservices crowd, waiting on humans to provision infrastructure is anathema.

Java is once again moving with the times, which is handy for everybody out there in possession of Java skills in today’s cloudy, DevOpsy and composable infrastructure-defined world. That’s because microservices comes down not to the language you use but how applications are designed, not the tools used to write them. With MicroProfile, at least, Java devs are on more equal terms.

The post With microservices Java can at last join us in our cloudy, DevOpsy world appeared first on Artificial Intelligence.

We’ve had a few articles over the years on the differences and similarities between SOA and microservices. Some suggest there is much to be learned from SOA whereas others believe that distancing microservices from SOA is more beneficial. Furthermore, Neal Ford amongst others, have suggested that moving from monolithic architectures to a services-based approach may be easier than going to microservices. There has not been much activity recently around the overall “SOA or microservices” debate until RedMonk’s Stephen O’Grady published an article on the subject. In it Stephen suggests that the size of the service is not the deciding factor, similar to what others have argued over the years such as Dan North and separately Jeppe Cramon stated:

Using only size for defining microservices is a poor measure and useless for determining whether a service has the right responsibilities

In fact Stephen believes these are a lot of facts behind the association between SOA and microservices:

For all of its other faults, SOA was a vision of enterprises that looks remarkably like what progressive organizations are building today with cloud native architectures composed of, among other things, microservices. Stripped to its core, SOA was the idea that architectures should be composed of services rather than monolithic applications.

Within his article Stephen has produced a couple of nice diagrams using Google Trends and the first shows that despite its popularity, SOA peaked and was popular for a relatively short period of time in the industry.

Stephen believes that the argument about size as a differentiator ignores or obscures the real reason why SOA dropped in popularity and microservices came on the scene: in his view SOA was a vendor driven effort whereas microservices is driven far more by developers.

Given the success of platforms such as AWS, it’s difficult to make the argument that service driven platforms are not an effective way of building platforms that scale or that they’re not the dominant approach at present. But notably, service-based platforms are generally developer constructs at present. The SOA-driven world originally envisioned by large vendors, one in which services were built out upon a byzantine framework of complex (and frequently political) “standards” never came to pass for the simple reason that developers wanted no part of it.

Stephen mentions that microservices do benefit from SOA, both on what worked and what did not work.

Microservices are easier for them to develop than monolithic alternatives, and come without the vendor standards baggage of SOA […]

Others have made the same argument over the last few years, including Asanka who said:

Today, enterprises are moving toward a clean SOA and embracing the concept of an MSA within a SOA. Possibly the biggest draws are the componentization and single function offered by these microservices that make it possible to deploy the component rapidly as well as scale it as needed. It isn’t a novel concept though.

And the second Google Trends graph Stephen shows is also interesting.

The post The Difference Between SOA and Microservices? appeared first on Artificial Intelligence.