Microservices Expo Authors: Liz McMillan, Pat Romanski, Elizabeth White, Derek Weeks, Mehdi Daoudi

Related Topics: Microservices Expo

Microservices Expo: Article

Understanding the Web Services Vision

Understanding the Web Services Vision

Web services is the latest trend in distributed computing. Based on sending XML messages that are transported over the HTTP protocol, the initial work has created a distributed computing model that is simple, easy, and lightweight. Most importantly, it works over the Internet.

  • Simple Object Access Protocol (SOAP) has brought interoperability between disparate systems over the Internet, providing distributed computing based on open Web standards. This complements existing approaches to interoperability, for example CORBA or messaging standards.
  • Web Services Description Language (WSDL) provides a framework for describing Web services based on XML and XML Schema. WSDL allows different systems and tools to understand and communicate with services provided by other technologies and organizations.

    Two discovery technologies allow Web services to be discovered on the Internet or on a network:

  • Web Services Inspection Language (WSIL) allows a server to publish the set of services available for a particular domain.
  • Universal Description, Discovery, and Integration (UDDI) allows businesses to publish information about their business and the services it offers, and others to search the directory for businesses and services. Organizations can also use UDDI within their enterprise.

    Web Services Motivation

    The Web today is fundamentally designed around human-to-machine interactions, with little semantic description. Now there is a requirement for a Web-based technology that supports application-to-application communication. This is driven by a number of needs, including:

  • The "Portal" model: Many companies have developed highly customized Web sites where users can access the majority of information, content, and function that they require from a single consolidated Web page. This model requires Web sites to communicate with each other.
  • The growth of electronic business-to-business transactions (B2B): Many standards exist for B2B, including EDI, RosettaNet, cXML, and others. These traditionally solve well-defined, systematic approaches to B2B. The growth of the Internet has put pressure on the technology to provide lightweight, inexpensive Web-based communications standards for B2B, with special focus on dynamic discovery and self-description of services.
  • Enterprise Application Integration (EAI): Many companies have put in place integration of applications across a wide variety of technology. In order to create efficient and effective channels to market, it is often necessary to connect together systems as diverse as mainframe systems, customer relationship systems, databases, accounting systems, and Web application servers. The push to e-business has meant that businesses are exposing their processes and systems directly to customers over the Web.

    We believe Web services offers a number of core benefits that allow application-to-application communication over the Web or intranet.

    XML and Open Web Standards:
    XML and HTTP are important because they offer:

    • A technology-neutral approach
    • Universal availability
    • An appropriate document model for loosely coupled systems
    • A vendor-neutral approach
    • Support for existing Web infrastructure like firewalls.
    Services-Oriented Architecture
    Web services focuses on describing the interactions between parties rather than the provider of the service. In particular this is important for distributed heterogeneous communications, where the implementations may vary significantly, but the interface should be constant.

    Description and Discovery
    The combination of WSDL and UDDI allows someone to search and locate a service, and create a client to that service - without requiring access to code repositories, common technologies, or even the same tools as the service provider. This organizational loose coupling has been a major driver to the growth of the Web. For example, many Web sites benefit from links, both to and from their Web sites, which did not involve any organizational involvement between the Web site owners.

    Messaging and Request-Response Models
    Typically, there has been a split in the technologies between tightly coupled request-response (RPC) behavior, and loosely coupled messaging systems. Both SOAP and WSDL accommodate both models in a single set of standards, making them suitable for both client-server and integration (B2B and EAI). This unifies the programming model for cross-Internet integration as well as supporting existing intra-enterprise optimizations. In this article we present a wider view of Web services as the basis of a services-oriented architecture (SOA). In particular, we show how Web services can be used in the portal, B2B, and EAI models, and how the notion of description and discovery can be extended to provide a rich model for interaction across multiple technologies.

    Building and Using Web Services
    The Web services standards only describe the outside interface of a service. Those interfaces imply some internal structure and semantics but the requirement to implement a Web service is very minimal. A number of technologies can be used - for example, simple Java classes; Enterprise JavaBeans; scripts such as VBScript, Python, or JavaScript; or C/C++ programs or objects can all be the implementation of a Web service. In fact, many other technologies, such as relational database stored procedures or legacy transactions can also implement Web services. There are three common models.

    Bottom-up Development
    An existing application function, such as an Enterprise JavaBean component or Java class, is exposed as a Web service. A tool examines the structure of the component, and generates the Web services description (WSDL file), which may be published using WSIL or UDDI. Often the tool will also generate deployment information, which configures a server to support and provide that service - to configure the SOAP support and other protocol enablement, and to "route" incoming requests to the underlying original component. The component does not need to understand XML, SOAP, or other formats, as the server transforms the SOAP request into the invocation mechanism of the original component.

    Tools which support this include the IBM WebSphere Studio Application Developer, IBM Web Services Tool Kit, and the Axis Java2WSDL. Once the component is deployed, users can download the published WSDL description and use any WSDL-aware tool to create a stub or proxy object. That object gives them an interface in the language they are programming in, such as a Java class or .NET business object, which can be invoked and will generate the SOAP message across the network.

    In this model, the service definition exists already. For example, a parcel delivery firm wishes to implement a Web service that allows tracking of parcels. There is an existing common interface, which is published in UDDI as a tModel. The developer of the Web service downloads the WSDL from the Internet, and uses a tool to create a skeleton. The skeleton is a component that has the structure but no business logic. The developer then creates the business logic that accesses the existing parcel tracking system. The new component calls the existing business logic, but exposes it with the common Web service interface. The service is published in UDDI with the same tModel as other parcel tracking systems. Existing parcel tracking clients, written to that tModel, are able, to invoke the new service.

    There is a third model - top-down - which we will address later. This model is similar to meet-in-the-middle, except that new business logic is necessary to implement the service.

    Implementing Web Services in a Java Environment
    Recently, there has been a great deal of work on Java standards for Web services in the Java Community Process, creating standards for using, developing, and deploying Web services in the Java and J2EE environments.

    3.1 JAX-RPC
    The Java API for XML-RPC (JAX-RPC) is a standard which defines to invoke and interact with Web services. JAX-RPC allows a user to access a stub or proxy for the service, or to use a Call interface that offers more direct access to the underlying SOAP invocation. JAX-RPC also defines a standard mapping from WSDL to Java interfaces, allowing tools to generate standardized interfaces for accessing Web services; in addition, the specification defines a standard mapping from Java interfaces to WSDL descriptions. At the time of writing, the JAX-RPC specification was about to become final. The Apache Axis project is currently building an implementation of JAX-RPC.

    JSR109 - Implementing Enterprise Web Services
    JSR109 is the ongoing standards activity on how to implement Web services in a J2EE environment. Included in the standard are:

    • How to implement Web services in a J2EE environment consistent with the J2EE programming model
    • How to deploy Web services implementations in a J2EE environment
    • How to locate Web services from within a J2EE environment
    • How to use Web services as a client consistent with the J2EE programming model
    • How to protect and secure Web services using J2EE security technology
    JSR109 adds Web Services deployment descriptors to support deployment of Web services. It builds upon the view of Web services provided by JAX-RPC and supports the deployment of JAX-RPC clients and service implementations. At the time of this writing, JSR109 was about to enter Public Review.

    Other Standards
    There are a number of other Java specifications and open-source contributions available or being developed. Some of the more significant ones for Web services are:

  • JWSDL: A simple, extensible API for reading, writing, and creating WSDL documents, backed by an open-source implementation.
  • JAX-B (XML Binding): Defines how to translate from Java classes to XML schema and back again.
  • JAX-R (XML Registries): Defines an API for accessing service registries including UDDI and ebXML Registry and Repository.
  • J2ME Web Services Specification: For use of Web services on pervasive devices; this is just getting started.
  • XML Digital Signature, XML Digital Encryption, and XML Key Management: JSRs that are developing Java bindings for their respective standards in the W3C's SOAP-SEC standard.
  • UDDI4J: An open-source API used to access UDDI directories.

    So far we've seen how the base Web-services standards fit together, and how they are implemented in a real environment. Now let's take a look at how we can use this technology, both in a B2B environment and in an EAI environment.

    Using Web Services in a B2B Context
    There are a number of initiatives for doing business-to-business electronic commerce. In particular, Electronic Data Interchange (EDI) has been very successful amongst large companies improving their supply-chain management. RosettaNet is another standard that has had success - especially in the electronic component marketplace. However, both of these initiatives, while successful in their own niches, have very limited success relative to the evolution of the Web and broad, cross-industry acceptance of HTTP, XML, etc. The result is that many companies are looking to leverage Web standards to build B2B solutions for e-commerce and e-business. We see the use of Web services developing very rapidly in B2B.

    There are two issues around this area.

    • Security and management
    • Process and conversation management
    One approach to addressing security and management is the use of a gateway. A gateway is a control point for external interactions. The gateway fills a role for B2B similar to what firewalls provide for more traditional uses of HTTP. For example, the gateway can provide an extra level of security and authorization, and logging of both incoming and outgoing service interactions. In addition, a Web services gateway can provide a layer of indirection and protocol switching, which adds security and allows enterprises to use existing protocols and still provide Internet protocols for external users. IBM has made available a Web Services Gateway Preview.

    The second issue with using Web services in a B2B scenario is that currently Web services are strictly "one-shot" interactions, whereas typical B2B interactions are ongoing, bi-directional, long-running, and correlated. However, there have been some proposals on how to manage a set of interactions as part of a process. In particular, XLANG from Microsoft and the Web Services Flow Language from IBM both address this issue. It is likely that a common cross-industry standard will emerge which will allow standardization of the processes between companies using Web services.

    Using Web Services in an EAI Context
    A number of vendors and companies have seen Web services as an approach to support Enterprise Application Integration. Many first Web services projects and pilots have been based on connecting Microsoft COM systems to Java and CORBA systems: for example, using J2EE as their application server and using COM-based Windows tools to build the clients. SOAP and WSDL allow them to create simple proxy objects on the client, which can invoke services running on the server in an effective manner.

    This approach also ties into the work many organizations began in 2000 and 2001 to standardize their internal integration on XML languages. Many companies built integration on top of industry-standard XML grammars, and this architecture fits very readily into the Web services paradigm. SOAP and WSDL support document-style interaction: in this model, the SOAP envelope is used to transmit an XML document that is defined by an existing XML Schema, allowing SOAP to be used as a messaging format for existing XML languages.

    A number of packaged application vendors have identified this as an approach to open up their systems to simple lightweight access, and this is likely to increase the use of Web services technology as a basis of EAI.

    There have traditionally been two very different approaches to integration. One approach is generally based on asynchronous one-way messaging, which is used to integrate widely divergent systems across large geographies and different technologies. This approach is typically based on document interchange. The other approach is based on tightly coupled synchronous integration, for example using remote procedure calls or CORBA and its description language (IDL) to call objects directly. This is typically used in single locations, with high-bandwidth, highly available systems, and is typically based on strictly typed interactions. Both SOAP and WSDL include both of these concepts: RPC-based interactions using typed interfaces and document-based one-way messaging. This gives Web services a very powerful approach to subsume and support both approaches.

    Web services need to meet the existing level of expectation in EAI technologies. There are a number of high-quality (and high-cost!) EAI technologies that offer essential facilities such as transformation, adaption, process management, reliability, high performance, monitoring, and metadata repositories. Web services offers a different set of benefits: low cost of entry, open standards based, and truly heterogeneous.

    Moving Beyond SOAP to a WSDL-Centric View
    WSDL forces a true separation of interface and implementation. This allows a separation of the business logic and the infrastructure - and is probably the most important aspect of the SOA. In general, application developers should concentrate on the abstract interface defined by the interface, and the deployers and administrator should concentrate on the infrastructure.

    As stated earlier, SOAP is the key component for building systems that can interoperate across the Web, but the real benefit of Web services is for building distributed systems where the service implementation is unimportant to the user of the service. What is important are the interface and its description. This motivates us to move our attention from SOAP to WSDL, and in particular to developing our models based on the interface or PortType of a service.

    There are a number of approaches and technologies that are being developed that take this approach.

    Top-down Development
    Earlier we described bottom-up and meet-in-the-middle development. The other approach is to do top-down development. In this model, the business analyst builds a UML model or business process. This is an abstract description of the interaction or the process. From this the WSDL PortType can be generated. Outside of Web services, this model is used very successfully as it tends to produce systems that closely match the requirements and the business model. From a Web services viewpoint it also works well because it fits the Web services model, and tooling exists to then create implementation objects from the WSDL definitions. This scenario describes an approach known as Model-Driven Architecture.

    Business Process Management
    Once sets of services are available via SOAP and described and published, it becomes very desirable to be able to build new processes using those services. Typically, programmers in the past have used programming languages to code the flows of a process, in which it is very easy to capture the "success case" - the normal handling of a particular process. However, often the fault cases are complex. In particular, if the individual activities in the process are distributed and loosely coupled - for example provided by another organization across the Web - then we need to have smart compensation logic in order to handle the fault cases, because traditional two-phase commit protocols are not appropriate in loosely coupled environments.

    A different model is to describe the process using a business process description language. These "flow" languages capture the relationship between services and the steps in the business process. An engine then runs this process, and if faults occur, the engine takes appropriate compensation action. Work is ongoing to develop a standard Web services language for describing business processes, where the process is described completely in terms of the interfaces/PortTypes of the individual services, and the bindings are defined at deployment time. Building business processes becomes a matter of composing existing services.

    Web Services Invocation Framework
    Earlier, we described how WSDL was inherently extensible, and independent of implementation type. Adding extensibility elements to WSDL allows the creation of descriptions of other service implementations than SOAP. Typically, Web services are implemented using existing application components - such as Java classes, Enterprise JavaBeans, or COM objects. These components are also sometimes wrappers onto legacy systems, such as mainframe transaction systems. We can capture the dependence relationship between these by extending WSDL to describe the existing component models, the exposed SOAP-available service, and the underlying component. In effect, we are adding the description capability of the SOA to the existing component model.

    WSDL is not just a description layer - it has a real implementation in tools that can use WSDL descriptions to generate stubs that can access the services. So if we add descriptions of non-SOAP systems, we are in danger of losing that benefit. The Web Services Invocation Framework (WSIF) addresses that. Effectively, it is a pluggable framework, that allows providers to be plugged in. A provider is code that supports a WSDL extension and allows invocation of the service through that particular implementation.

    This means that the client code is independent of the implementation. WSIF also allows late binding, where an existing client can use a new implementation at runtime - even over a new protocol or transport. WSIF also allows the infrastructure and runtime to choose the best implementation on the basis of quality-of-service characteristics or business policy.

    Provisioning is the ability to host services and charge clients for their use. For the Web services vision to become real, it will be necessary to be able to sell services and to identify who is using them, and how often. Provisioning is not based on the underlying SOAP message, but instead on understanding the range of services and how they fit to contracts. In order for a service to be provisioned, there must be a contract with a given identified user or organization, and then each use of the service must check if there is an applicable contract and then be metered. From the metering, a rating engine can identify the cost under the right contract and generate an invoice for the usage.

    The Web Service Hosting Toolkit (WSHT) is a toolkit that offers the ability to provision services, irrespective of how they are implemented and deployed.

    In this article we have seen a progression, from the base Web services standards bringing point-to-point interoperability using XML and HTTP, all the way to dynamic invocation and composition of services using higher order description languages. Our vision is of an SOA that:

    • Encompasses both messaging and RPC approaches
    • Supports discovery and description of services
    • Enables both business-to-business communications and enterprise application integration
    • Allows composition of services into business processes
    • Enables the metering, monitoring, and contracting of services
    In our vision of Web services, there is a clear distinction between the business logic process and interfaces and the underlying infrastructure that provides them, through meta-data and XML descriptions such as WSDL and process descriptions.

    We recognize that there is still a long way to go in the Web services technology for the greater marketplace - in particular, there are requirements to address and standardize:

    • Composition and choreography
    • Complex end-to-end security models
    • Support for reliability
    • Business transaction models
    • A framework for business trust
    These efforts are underway, but that shouldn't stop the technology from being used today. The production environments exist to allow Web services to be deployed, described, published, and accessed today. Early implementations exist that show how Web services can be exposed to partners, composed, and provisioned. Finally there is a vision and a roadmap that is shared by a number of vendors that are delivering on a new service-oriented model of computing.


  • Standards: www.w3.org and www.uddi.org.
  • Java Standards: www.jcp.org.
  • CORBA, UML, and MDA: www.omg.org.
  • Web Services and Open Source Portal: www.ibm.com/developerworks.
  • Open Source Web Services: http://xml.apache.org.
  • IBM WebSphere: www.ibm.com/websphere.
  • IBM Previews: www.alphaworks.ibm.com.
  • More Stories By Heather Kreger

    Heather Kreger is IBM’s lead architect for SOA Standards in the IBM Software Group, with 15 years of standards experience. She has led the development of standards for Web services, Management and Java in numerous industry standards groups including W3C, OASIS, DMTF, and The Open Group. Heather is the author of numerous articles and specifications, as well as the book “Java and JMX, Building Manageable Systems,” and most recently was co-editor of “Navigating the SOA Open Standards Landscape Around Architecture.”

    More Stories By Donald F. Ferguson

    Don Ferguson is Corporate Senior VP, Distinguished Engineer, Chief Architect Products and Technology at CA. Formerly, at IBM, he was the visionary behind WebSphere.

    More Stories By Sanjiva Weerawarana

    Sanjiva Weerawarana is a research staff member in the Component Systems Group at IBM's TJ Watson Research Center. He is one of the coauthors of the WSDL and WSFL specifications, and a codeveloper of Apache SOAP, WSTK, WSDL Toolkit, WSIF, and WSGW. He holds a PhD in computer science from Purdue University.

    More Stories By Paul Fremantle

    Paul Fremantle is a Web services architect in IBM's Hursley Laboratory. Paul has been working with Java, XML, and Web technologies since 1994, and is one of the architects of IBM's Web Services Invocation Framework and the Web Services Gateway. Paul is the coauthor of The XML Files, an IBM Redbook, as well as technical papers on WebSphere. He has an MA in mathematics and philosophy from Oxford University and an MSc in computation.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

    @MicroservicesExpo Stories
    As many know, the first generation of Cloud Management Platform (CMP) solutions were designed for managing virtual infrastructure (IaaS) and traditional applications. But that's no longer enough to satisfy evolving and complex business requirements. In his session at 21st Cloud Expo, Scott Davis, Embotics CTO, explored how next-generation CMPs ensure organizations can manage cloud-native and microservice-based application architectures, while also facilitating agile DevOps methodology. He expla...
    SYS-CON Events announced today that Synametrics Technologies will exhibit at SYS-CON's 22nd International Cloud Expo®, which will take place on June 5-7, 2018, at the Javits Center in New York, NY. Synametrics Technologies is a privately held company based in Plainsboro, New Jersey that has been providing solutions for the developer community since 1997. Based on the success of its initial product offerings such as WinSQL, Xeams, SynaMan and Syncrify, Synametrics continues to create and hone in...
    DevOps promotes continuous improvement through a culture of collaboration. But in real terms, how do you: Integrate activities across diverse teams and services? Make objective decisions with system-wide visibility? Use feedback loops to enable learning and improvement? With technology insights and real-world examples, in his general session at @DevOpsSummit, at 21st Cloud Expo, Andi Mann, Chief Technology Advocate at Splunk, explored how leading organizations use data-driven DevOps to clos...
    "I focus on what we are calling CAST Highlight, which is our SaaS application portfolio analysis tool. It is an extremely lightweight tool that can integrate with pretty much any build process right now," explained Andrew Siegmund, Application Migration Specialist for CAST, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
    The dynamic nature of the cloud means that change is a constant when it comes to modern cloud-based infrastructure. Delivering modern applications to end users, therefore, is a constantly shifting challenge. Delivery automation helps IT Ops teams ensure that apps are providing an optimal end user experience over hybrid-cloud and multi-cloud environments, no matter what the current state of the infrastructure is. To employ a delivery automation strategy that reflects your business rules, making r...
    The past few years have brought a sea change in the way applications are architected, developed, and consumed—increasing both the complexity of testing and the business impact of software failures. How can software testing professionals keep pace with modern application delivery, given the trends that impact both architectures (cloud, microservices, and APIs) and processes (DevOps, agile, and continuous delivery)? This is where continuous testing comes in. D
    Modern software design has fundamentally changed how we manage applications, causing many to turn to containers as the new virtual machine for resource management. As container adoption grows beyond stateless applications to stateful workloads, the need for persistent storage is foundational - something customers routinely cite as a top pain point. In his session at @DevOpsSummit at 21st Cloud Expo, Bill Borsari, Head of Systems Engineering at Datera, explored how organizations can reap the bene...
    Admiral Calcote - also known as Lee Calcote (@lcalcote) or the Ginger Geek to his friends - gave a presentation entitled Characterizing and Contrasting Container Orchestrators at the 2016 All Day DevOps conference. Okay, he isn't really an admiral - nor does anyone call him that - but he used the title admiral to describe what container orchestrators do, relating it to an admiral directing a fleet of container ships. You could also say that they are like the conductor of an orchestra, directing...
    The past few years have seen a huge increase in the amount of critical IT services that companies outsource to SaaS/IaaS/PaaS providers, be it security, storage, monitoring, or operations. Of course, along with any outsourcing to a service provider comes a Service Level Agreement (SLA) to ensure that the vendor is held financially responsible for any lapses in their service which affect the customer’s end users, and ultimately, their bottom line. SLAs can be very tricky to manage for a number ...
    Our work, both with clients and with tools, has lead us to wonder how it is that organizations are handling compliance issues in the cloud. The big cloud vendors offer compliance for their infrastructure, but the shared responsibility model requires that you take certain steps to meet compliance requirements. Which lead us to start poking around a little more. We wanted to get a picture of what was available, and how it was being used. There is a lot of fluidity in this space, as in all things c...
    Gaining visibility in today’s sprawling cloud infrastructure is complex and laborious, involving drilling down into tools offered by various cloud services providers. Enterprise IT organizations need smarter and effective tools at their disposal in order to address this pertinent problem. Gaining a 360 - degree view of the cloud costs requires collection and analysis of the cost data across all cloud infrastructures used inside an enterprise.
    Some people are directors, managers, and administrators. Others are disrupters. Eddie Webb (@edwardawebb) is an IT Disrupter for Software Development Platforms at Liberty Mutual and was a presenter at the 2016 All Day DevOps conference. His talk, Organically DevOps: Building Quality and Security into the Software Supply Chain at Liberty Mutual, looked at Liberty Mutual's transformation to Continuous Integration, Continuous Delivery, and DevOps. For a large, heavily regulated industry, this task...
    The goal of Microservices is to improve software delivery speed and increase system safety as scale increases. Microservices being modular these are faster to change and enables an evolutionary architecture where systems can change, as the business needs change. Microservices can scale elastically and by being service oriented can enable APIs natively. Microservices also reduce implementation and release cycle time and enables continuous delivery. This paper provides a logical overview of the Mi...
    The notion of improving operational efficiency is conspicuously absent from the healthcare debate - neither Obamacare nor the newly proposed GOP plan discusses the impact that a step-function improvement in efficiency could have on access to healthcare (through more capacity), quality of healthcare services (through reduced wait times for patients) or cost (through better utilization of scarce, expensive assets).
    Gone are the days when application development was the daunting task of the highly skilled developers backed with strong IT skills, low code application development has democratized app development and empowered a new generation of citizen developers. There was a time when app development was in the domain of people with complex coding and technical skills. We called these people by various names like programmers, coders, techies, and they usually worked in a world oblivious of the everyday pri...
    The “Digital Era” is forcing us to engage with new methods to build, operate and maintain applications. This transformation also implies an evolution to more and more intelligent applications to better engage with the customers, while creating significant market differentiators. In both cases, the cloud has become a key enabler to embrace this digital revolution. So, moving to the cloud is no longer the question; the new questions are HOW and WHEN. To make this equation even more complex, most ...
    Some journey to cloud on a mission, others, a deadline. Change management is useful when migrating to public, private or hybrid cloud environments in either case. For most, stakeholder engagement peaks during the planning and post migration phases of a project. Legacy engagements are fairly direct: projects follow a linear progression of activities (the “waterfall” approach) – change managers and application coders work from the same functional and technical requirements. Enablement and develo...
    Kubernetes is an open source system for automating deployment, scaling, and management of containerized applications. Kubernetes was originally built by Google, leveraging years of experience with managing container workloads, and is now a Cloud Native Compute Foundation (CNCF) project. Kubernetes has been widely adopted by the community, supported on all major public and private cloud providers, and is gaining rapid adoption in enterprises. However, Kubernetes may seem intimidating and complex ...
    You know you need the cloud, but you’re hesitant to simply dump everything at Amazon since you know that not all workloads are suitable for cloud. You know that you want the kind of ease of use and scalability that you get with public cloud, but your applications are architected in a way that makes the public cloud a non-starter. You’re looking at private cloud solutions based on hyperconverged infrastructure, but you’re concerned with the limits inherent in those technologies.
    For DevOps teams, the concepts behind service-oriented architecture (SOA) are nothing new. A style of software design initially made popular in the 1990s, SOA was an alternative to a monolithic application; essentially a collection of coarse-grained components that communicated with each other. Communication would involve either simple data passing or two or more services coordinating some activity. SOA served as a valid approach to solving many architectural problems faced by businesses, as app...