Welcome!

Microservices Expo Authors: Stackify Blog, Aruna Ravichandran, Dalibor Siroky, Kevin Jackson, PagerDuty Blog

Related Topics: Microservices Expo, Java IoT, Industrial IoT, Containers Expo Blog, Agile Computing, @CloudExpo

Microservices Expo: Blog Feed Post

From ESBs to API Portals, an Evolutionary Journey | Part 2

SOA transformation in the big enterprise

In this article series we would like to build a case that API portals, with the Intel® API Manager and Intel® Expressway Service Gateway, powered by Mashery are representative examples, are the contemporary manifestations of the SOA movement that transformed IT in the early 2000s from IT as a cost center to an equal partner in a company’s  execution of a business strategy and revenue generation.  In the introductory article in Part 1 we discussed some of the business dynamics that led to cloud computing and the service  paradigm.  Let’s now take a closer look  at the SOA transformation in the big enterprise.

If we look at the Google  Webtrends graph for the term “SOA”, we can use the search popularity as an  indicator of the industry we can see that the interest in SOA peaked at around  2007, just as the interest on cloud computing started rising.  There was a brief burst of interest on this term at the end of 2012 which can be attributed at people looking for precedents in SOA as the industry moves to cloud services.

Figure 1. Google Webtrends graph for “SOA.”

Figure 2. Google Webtrends graph for “Cloud Computing.

The search rate for the term “cloud computing” actually peaked in 2011, but perhaps unlike SOA, the trend is not an indication of waning interest, but that the focus of interest has shifted to more specific aspects. See for instance the graphs for “Amazon AWS” and “OpenStack”.

Figure 3. Google Webtrends graph for “Amazon AWS.”

Figure 4. Google Webtrends graph for “OpenStack.”

SOA brought a discipline of  modularity that has been well known in the software engineering community for more than 30 years, but had been little applied in corporate-wide IT  projects.  The desired goal for SOA was  to attain a structural cost reduction in the delivery of IT services through  re-use and standardization.  These savings needed to be weighed against significant upfront costs for architecture and planning as well as from the reengineering effort for interoperability and security.  The expectation was a per  instance lower cost from reuse in spite of the required initial investment.

Traditionally, corporate applications have been deployed in stovepipes, as illustrated in Figure 5 below, one application per server or server tier hosting a complete solution stack.  Ironically, this trend was facilitated by the availability of low-cost Intel-based high volume servers starting fifteen years ago.  Under this system physical servers need to be procured, a process that takes anywhere from two weeks to six months depending on organizational policies and asset approvals in effect.  When the servers become available, they need to be configured and provisioned with an operating system, database software, middleware and the application. Multiple pipes are actually needed to support a running business.  For instance, Intel IT requires as many as 15 staging stovepipes to phase in an upgrade for the Enterprise Resource Planning (ERP) SAP application.  The large number of machines needed to support most any corporate application over its life cycle led to the condition affectionately called “server sprawl.”  In data centers housing thousands if not tens of thousands of servers it is not difficult to lose track of these assets, especially after project and staff turnover from repeated reorganizations and M&As.  This created another affectionate term: “zombies.”  These are forgotten servers from projects past, still powered up, and even running an application, but serving no business purpose.

Figure 5. Traditional Application Stovepipes vs. SOA.

With SOA, monolithic applications are broken into reusable, fungible services as shown on the left side of Figure 6 below.  Much in the same way server sprawl used to exist in data centers, so it was with software, with multiple copies deployed, burdening IT organizations with possibly unnecessary licensing costs, or even worse, with shelfware, that is, licenses paid for software never used.  As an example, in a stovepiped environment each application that requires the employee roster of a company, namely user accounts, phone directory, expense reporting, payroll would each require a full copy of the employee information database.  In addition to the expense of the extra copies, the logistics of keeping each copy synchronized would be complex.

What if instead the need to replicate the employee roster somehow it was possible to build a single copy where every application needing this information can “plug in” into this copy and use it a needed.  There are some complications: the appropriate access and security mechanisms need to be in place.  Locking mechanisms for updates need to be implemented to ensure integrity and consistency of the data.  However the expense of habilitating the database for concurrent access is still significantly less than the expense of maintaining several copies.

If we access this new single-copy employee database through Web Services technology, using either SOAP or REST, we have just created a “service”, the “employee roster service”.  If every application layer in a stack is
re-engineered as a service with possibly multiple users, the stacks in Figure 5 morph into a network as shown in the left part of Figure 6. The notion of service is recursive where most applications become composites of several services and services themselves are composites of services.  Any service can be n “application” if it exposes a user interface (UI) or a service proper if it exposes an API.  In fact a service can be both, exposing multiple UIs and APIs depending on the intended audience or target application: it is possible to have one API for corporate access and yet another one available to third party developers of mobile applications.

Applications structured to operate under this new service paradigm are said to follow a service oriented architecture, commonly known as SOA.  The transition to SOA created new sets of dynamics whose effects are still triggering change today.  For one thing, services are loosely coupled, meaning that as long as the terms of the service contract between the service consumer and the service provider does not change, one service instance can be easily replaced. This feature simplifies the logistics of deploying applications enormously: a service can be easily replaced to improve quality, or ganged together with a similar service to increase performance or throughput.  Essentially applications can be assembled from services as part of operational procedures.  This concept is called “late binding” of application components.

Historically binding requirements have been loosened up over time.  In earlier times most applications components had to be bound together at compile time.  This was really early binding.  Over time it became possible to combine precompiled modules using a linker tool and precompiled libraries.  With dynamically linked libraries it became possible to bind together binary objects at run time.  However this operation had to be done within a given operating system, and allowed only within strict version or release limits.

We can expect even more dynamic applications in the near future.  For instance, it is not hard to imagine self-configuring applications assembled on the fly and real time on demand using a predefined template.  In theory these applications could recreate themselves in any geographic region using locally sourced service components.

There are also business considerations driving the transformation dynamics of application components. Business organizations are subject to both headcount and budgetary constraints for capital expenses.  Under these restrictions it may be easier for an organization to convert labor and capital costs into monthly operational expenses by running their services on third party machines hiring Infrastructure as a Service (IaaS) cloud services, or take one step further and contract out the complete database package to implement the employee roster directly from a Software as a Service (SaaS) provider.  All kinds of variations are possible: the software service may be hosted on infrastructure from yet another party, contracted by either the SaaS provider or the end user organization.

The effect of the execution of this strategy is the externalization of some of the services as shown in the right hand side of Figure 6.  We call this type of evolution inside-out SOA where initially in-sourced service components get increasingly outsourced.

Figure 6. The transition from internal SOA to inside-out SOA.

As with any new approach, SOA transformation required an upfront investment, including the cost of reengineering the applications and breaking them up into service components, and in ensuring that new applications themselves or new capabilities were service ready or service capable.  The latter usually meant attaching an API to an application to make the application usable as a component for a higher-level application.

Implementation teams found the extra work under the SOA discipline disruptive and distracting.  Project participants resented the fact that while this extra work is for the “greater good” of the organization, it was not directly aligned with the goals of the project.  This is part of the cultural and behavioral aspects that a SOA program needs to deal with, which can be more difficult to orchestrate than the SOA technology itself. Most enterprises that took a long term approach and persisted in these efforts eventually reached a breakeven point where the extra implementation cost of a given project was balanced by the savings by reusing past projects.

This early experience also had another beneficial side effect that would pave the way to the adoption of cloud computing a few years later: the development of a data-driven, management by numbers ethic demanding quantifiable QoS and a priori service contracts also known as SLAs or service level agreements.

While the inside-out transformation just described had a significant impact in the architecture of enterprise IT, the demand for third party service components had an even greater economic impact on the IT industry as a whole, leading to the creation of new supply chains and with these supply chains, new business models.

Large companies, such as Netflix, Best Buy, Expedia, Dun & Bradstreet and The New York Times found that the inside-out transformative process was actually a two-way street.  These early adopters found that making applications
“composable” went beyond saving money; it actually helped them make money through the enablement of new revenue streams: the data and intellectual property that benefited internal corporate departments was also useful to external parties if not more.  For instance an entrepreneur providing a travel service to a corporate customer did not have to start from ground zero and making the large investment to establish a travel reservation system.  It was a lot simpler to link up to an established service such as Expedia.  In fact, for this upstart did not have to be bound by a single service: at this level it makes more economic sense to leverage a portfolio of services, in which case the value added of this service upstart is in finding the best choices from the portfolio.  This is a common pattern in product search services whose function is to find the lowest price across multiple stores, or in the case of a travel service, the lowest priced airfare.

The facilitation of the flow of information was another change agent for the industry.  There was no place to hide.  A very visible example is effect of these dynamics on the airline industry, and how it changed irrevocably, bringing up new efficiencies but also significant disruption.  The change empowered consumers, and some occupations such as travel agents and car salespeople were severely impacted.

Another trend that underlies the IT industry transformation around services is the “democratization” of the services themselves: The cost efficiencies gained not only lowered the cost of business for some expensive applications accessible only to large corporations with deep pockets; it made these applications affordable to smaller businesses, the market segment known as SMBs or Small and Medium Businesses.  The economic impact of this trend has been enormous, although hard to measure as it is still in process.  A third wave has already started, which is the industry’s ability to reduce the quantum for the delivery of IT services to make it affordable to individual consumers. This includes social media, as well as more traditional services such as email and storage services such as Dropbox. We will take a look at SMBs in Part 3.

The post From ESBs to API Portals, an Evolutionary Journey Part 2 appeared first on Security [email protected].

Read the original blog entry...

More Stories By Application Security

This blog references our expert posts on application and web services security.

@MicroservicesExpo Stories
How is DevOps going within your organization? If you need some help measuring just how well it is going, we have prepared a list of some key DevOps metrics to track. These metrics can help you understand how your team is doing over time. The word DevOps means different things to different people. Some say it a culture and every vendor in the industry claims that their tools help with DevOps. Depending on how you define DevOps, some of these metrics may matter more or less to you and your team.
For many of us laboring in the fields of digital transformation, 2017 was a year of high-intensity work and high-reward achievement. So we’re looking forward to a little breather over the end-of-year holiday season. But we’re going to have to get right back on the Continuous Delivery bullet train in 2018. Markets move too fast and customer expectations elevate too precipitously for businesses to rest on their laurels. Here’s a DevOps “to-do list” for 2018 that should be priorities for anyone w...
If testing environments are constantly unavailable and affected by outages, release timelines will be affected. You can use three metrics to measure stability events for specific environments and plan around events that will affect your critical path to release.
In a recent post, titled “10 Surprising Facts About Cloud Computing and What It Really Is”, Zac Johnson highlighted some interesting facts about cloud computing in the SMB marketplace: Cloud Computing is up to 40 times more cost-effective for an SMB, compared to running its own IT system. 94% of SMBs have experienced security benefits in the cloud that they didn’t have with their on-premises service
DevOps failure is a touchy subject with some, because DevOps is typically perceived as a way to avoid failure. As a result, when you fail in a DevOps practice, the situation can seem almost hopeless. However, just as a fail-fast business approach, or the “fail and adjust sooner” methodology of Agile often proves, DevOps failures are actually a step in the right direction. They’re the first step toward learning from failures and turning your DevOps practice into one that will lead you toward even...
DevOps is under attack because developers don’t want to mess with infrastructure. They will happily own their code into production, but want to use platforms instead of raw automation. That’s changing the landscape that we understand as DevOps with both architecture concepts (CloudNative) and process redefinition (SRE). Rob Hirschfeld’s recent work in Kubernetes operations has led to the conclusion that containers and related platforms have changed the way we should be thinking about DevOps and...
While walking around the office I happened upon a relatively new employee dragging emails from his inbox into folders. I asked why and was told, “I’m just answering emails and getting stuff off my desk.” An empty inbox may be emotionally satisfying to look at, but in practice, you should never do it. Here’s why. I recently wrote a piece arguing that from a mathematical perspective, Messy Desks Are Perfectly Optimized. While it validated the genius of my friends with messy desks, it also gener...
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 next XaaS is CICDaaS. Why? Because CICD saves developers a huge amount of time. CD is an especially great option for projects that require multiple and frequent contributions to be integrated. But… securing CICD best practices is an emerging, essential, yet little understood practice for DevOps teams and their Cloud Service Providers. The only way to get CICD to work in a highly secure environment takes collaboration, patience and persistence. Building CICD in the cloud requires rigorous ar...
The enterprise data storage marketplace is poised to become a battlefield. No longer the quiet backwater of cloud computing services, the focus of this global transition is now going from compute to storage. An overview of recent storage market history is needed to understand why this transition is important. Before 2007 and the birth of the cloud computing market we are witnessing today, the on-premise model hosted in large local data centers dominated enterprise storage. Key marketplace play...
The cloud revolution in enterprises has very clearly crossed the phase of proof-of-concepts into a truly mainstream adoption. One of most popular enterprise-wide initiatives currently going on are “cloud migration” programs of some kind or another. Finding business value for these programs is not hard to fathom – they include hyperelasticity in infrastructure consumption, subscription based models, and agility derived from rapid speed of deployment of applications. These factors will continue to...
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 ...
Following a tradition dating back to 2002 at ZapThink and continuing at Intellyx since 2014, it’s time for Intellyx’s annual predictions for the coming year. If you’re a long-time fan, you know we have a twist to the typical annual prediction post: we actually critique our predictions from the previous year. To make things even more interesting, Charlie and I switch off, judging the other’s predictions. And now that he’s been with Intellyx for more than a year, this Cortex represents my first ...
"Grape Up leverages Cloud Native technologies and helps companies build software using microservices, and work the DevOps agile way. We've been doing digital innovation for the last 12 years," explained Daniel Heckman, of Grape Up 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 Toyota Production System, a world-renowned production system is based on the "complete elimination of all waste". The "Toyota Way", grounded on continuous improvement dates to the 1860s. The methodology is widely proven to be successful yet there are still industries within and tangential to manufacturing struggling to adopt its core principles: Jidoka: a process should stop when an issue is identified prevents releasing defective products
We seem to run this cycle with every new technology that comes along. A good idea with practical applications is born, then both marketers and over-excited users start to declare it is the solution for all or our problems. Compliments of Gartner, we know it generally as “The Hype Cycle”, but each iteration is a little different. 2018’s flavor will be serverless computing, and by 2018, I mean starting now, but going most of next year, you’ll be sick of it. We are already seeing people write such...
Defining the term ‘monitoring’ is a difficult task considering the performance space has evolved significantly over the years. Lately, there has been a shift in the monitoring world, sparking a healthy debate regarding the definition and purpose of monitoring, through which a new term has emerged: observability. Some of that debate can be found in blogs by Charity Majors and Cindy Sridharan.
It’s “time to move on from DevOps and continuous delivery.” This was the provocative title of a recent article in ZDNet, in which Kelsey Hightower, staff developer advocate at Google Cloud Platform, suggested that “software shops should have put these concepts into action years ago.” Reading articles like this or listening to talks at most DevOps conferences might make you think that we’re entering a post-DevOps world. But vast numbers of organizations still struggle to start and drive transfo...
Let's do a visualization exercise. Imagine it's December 31, 2018, and you're ringing in the New Year with your friends and family. You think back on everything that you accomplished in the last year: your company's revenue is through the roof thanks to the success of your product, and you were promoted to Lead Developer. 2019 is poised to be an even bigger year for your company because you have the tools and insight to scale as quickly as demand requires. You're a happy human, and it's not just...
"Opsani helps the enterprise adopt containers, help them move their infrastructure into this modern world of DevOps, accelerate the delivery of new features into production, and really get them going on the container path," explained Ross Schibler, CEO of Opsani, and Peter Nickolov, CTO of Opsani, in this SYS-CON.tv interview at DevOps Summit at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.