T-Mobile

Top Apigee Customer Stories of 2018

From healthcare to telecommunications to financial services, Apigee customers across industries had a very successful 2018 deploying and managing APIs. 

We sat down with dozens of customers in 2018 to discuss their API programs and the ways that API management has helped them build successful businesses. Here are ten of the most popular videos from the year.

 

 

Flex: Improving Patient Outcomes with API Management

Flex's Ferry Tamtoro discusses how Apigee helps his company to meet customer needs.

For more, read the Flex case study.

 

Macquarie: Open APIs for Banking Innovation

Macquarie's Rajay Rai explains the importance of API management in innovating the Australian bank's customers and partners. 

 

 

How Apigee Customers Manage APIs as Products

Five Apigee customers—Telstra, West, Telenor, Tradier, and PwC—explain how they manage their APIs as products.

 

T-Mobile: Building a Telecom Platform with APIs

T-Mobile's Chuck Knostman explains how Apigee helped this telco services provider simplify how partners connect with the company to sell its services.

 

Tradier: Delivering Value to an Ecosystem

Tradier's Dan Raju explains how participating in an ecosystem enables a company to multiply the power of its offerings.

 

Telenor: Accelerating Partner Onboarding with Apigee

Telenor's Elisabeth Falck discusses how Apigee helps this telco digitize and accelerate the partner onboarding process.

For more, read the Telenor case study.

 

Rush University Medical Center: Enhancing the Patient Experience with Apigee

Rush's Dr. Shafiq Rab explains how Apigee helps this hospital communicate with patients and securely grant access to health data.

For more, read the Rush case study.

 

West: Simplifying IT Systems with Apigee

West's Thomas Squeo describes how this global provider of communications and network infrastructure services uses API management for internal product development, platform consolidation, and partnering.

 

Shutterfly: Boosting Partnerships and Development with Apigee 

Shutterfly's Jeff Nokes explains how adopting the Apigee platform helped his team improve the success of internal applications and external partner integrations.

 

Jackson National: Disrupting the Annuity Industry with APIs

Jackson National's Dana Malesky explains how Apigee helps this provider of variable annuities to modernize its offerings.

Check out the full library of our customer videos in our "Voices of Digital Business Pioneers" YouTube playlist. All of our customer stories are available on the Apigee resources page.

 

 

Demystifying Microservices

It’s easy to see why microservices have become so popular.

Netflix’s shift to microservices has famously helped it to serve up its content to so many different devices. Companies such as Twitter and Airbnb have leveraged microservices to dramatically accelerate development. South American retailer Magazine Luiza’s adoption of microservices has helped it transform from a brick-and-mortar company with basic e-commerce capabilities to, as some analysts have put it, the “Amazon of Brazil.”* In an age when delivering great digital experiences is more important than ever, microservices have shown themselves to be an important part of the mix.

But microservices are also notoriously complicated—in no small part because it’s not always clear what microservices even are. Are they basically just an evolved version of service-oriented architectures (SOA)? Since a microservice must be exposed via an application programming interface (API) for an organization to scale it to new developers, does that mean managing microservices is basically the same as managing APIs?

As this article will discuss, the answer to both of these questions is a clear “no” — and companies looking to get the most from their microservices need to understand why.

What are microservices anyway?

Broadly, the term “microservices” refers to a software development methodology organized around granular business capabilities that can be recombined at scale for new apps. A microservice architecture, then, is a method of developing software applications more quickly by building them as collections of independent, small, modular services.

A primary benefit of this architecture is to empower decentralized governance that allows small, independent teams to innovate faster. Rather than working as a large team on a monolithic application, these small teams work on their own granular services, share those services with others via APIs so the services can be leveraged for more apps and digital experiences, and avoid disrupting the work of other developers or end user experiences because each microservice can be deployed independently.

Microservices can be deployed independently and easily moved across clouds because—unlike monolithic applications—microservices are deployed in containers that include all the business logic the service needs to run. Developers can use APIs to create applications composed of services from multiple clouds, and microservices in one cloud can interact via APIs with systems elsewhere.

In more specific terms, microservices are:

  • fine-grained services that deliver a unique, single responsibility crucial to an overall business goal.
  • independent and event-driven. They share nothing with other microservices and can be deployed or replaced without impacting other services.
  • deployed separately but able to communicate with other services though a well-defined interface, generally RESTful APIs that expose the service for developer consumption.
  • code components that are typically replaced wholesale, rather than versioned, and can be disposed of without affecting other components of the architecture.
  • governed decentrally. Microservices architectures are generally incompatible with centralized legacy operational approaches that generally lock down IT assets and impose heavy governance. Microservices still requires some blanket governance practices—security concepts such as OAuth should apply to all APIs being used to consume microservices, for example. But it is important to let teams develop in the best way for them, with the best tools for their work and the autonomy to innovate.

How are businesses implementing microservices?

In many top businesses, the shift from a single development pipeline to multiple pipelines, and from waterfall development to automated continuous integration/continuous delivery (CI/CD) processes that facilitate rapid iteration, is already happening. Microservices are a major driver. Release cycles that were once long and arduous have now been reduced so that businesses can release daily or even multiple times in one day. Magazine Luiza, for example, leveraged microservices to accelerate from fewer than 10 deployments per month to more than 40 per day.

These changes emphasizes that microservices may not be useful when a company is merely trying to bolt technology onto its status quo business model. Rather, microservices are a way for businesses to use technology to change how they operate. If a company uses one large, slow-moving development team, microservices may not be much use until it has reorganized around dozens or even hundreds of small, fast-moving development teams. That transition doesn’t and typically won’t happen overnight—but microservices are built to empower small, independent teams, so a company may need at least skunkworks projects to get started.

In a blog post, T-Mobile CIO Cody Sanford describes this trend well:

“Gone are the highly-coupled applications, massive waterfall deliveries, broken and manual processes, and mounting technical debt. In their place are digital architecture standards, exposed APIs, hundreds of applications containerized and in the cloud, and a passionate agile workforce.”

If an organization is prepared to make the right organizational changes, microservices can accelerate multi-cloud strategies because the services can be scaled elastically, enabling more workloads to run in the cloud and across clouds. They can be deployed to create a more flexible architecture in which individual services can be released, scaled, and updated without impact to the rest of the system.

Monolithic applications contain all of the business logic, rules, authentication, authorization, and data tied together, which typically makes them much more difficult and time-intensive to update in even relatively modest ways. Microservices architecture, in contrast, support the separation of duties into individual self-contained entities that work together to deliver the full experience—instead of a team spending months or years creating tightly-coupled code for a single app, many teams create microservices daily or weekly that can be leveraged indefinitely in changing contexts.

How should I manage microservices?

For many businesses, the best way to manage microservices will be through a combination of a mesh network such as Istio and an API management platform. It’s important not to conflate these two things. The former handles service-to-service interactions, such as load balancing, service authentication, service discovery, routing, and policy enforcement. The latter provides the tools, control, and visibility to scale microservices via APIs to new developers and connect them via APIs to new systems.

More specifically, a service mesh can provide fine-grained visibility and insights into the microservices environment, control traffic, implement security, and enforce policies for all services within the mesh. The advantage is that it all happens without making changes to application code.

API management, meanwhile, provides for easy developer consumption of microservices. Organizations need APIs so that teams can share microservices and interact with other systems. These APIs should not be designed for simple exposure but rather as products designed and managed to empower developers. An API management platform should provide mechanisms to onboard and manage developers, create an API catalog and documentation, generate API usage reporting, productize or monetize APIs, and enforce throttling, caching, and other security and reliability precautions.

Consequently, microservices are distinct but deeply connected to APIs. Both APIs and microservices are also distinct from legacy SOA techniques in several crucial ways, including that microservices thrive in more decentralized environments with more autonomous teams and that the emphasis is not just on reusing digital assets but also making them easy to consume so that developers can leverage them in new ways.

Microservices: only one piece of the digital transformation puzzle

The benefits of microservices don’t typically emerge until a business needs to scale a service, both in terms of the number of requests it needs to handle and the number of developers who need to work with it. Additionally, while companies may break some existing systems into microservices or use microservices for current development goals, many older systems, such as enterprise service bus (ESB) or mainframe systems, will remain part of an enterprise’s overall topology. These heterogeneous systems typically communicate with one another via APIs, emphasizing again that though APIs are central to microservices, what can be done with a microservice and what can be done with an API are not the same.

Microservices will remain challenging as organizations continue to implement them — but with the right understanding of how microservices fit alongside other technologies and should be managed, this complexity may be more conquerable than it appears!

This article originally appeared in Medium.

To learn more, read the Apigee eBook, "Maximizing Microservices."  

Becoming the Un-Carrier: T-Mobile's Digital Transformation Journey

Companies that win in the digital economy share a common obsession: they're fanatical about delivering first-class digital experiences to their customers and partners.

One such company is T-Mobile. We were fortunate to be joined recently by this leading mobile services provider's vice president of IT Chuck Knostman. Chuck described how T-Mobile’s API-first mindset enables its IT and business teams to operate in lockstep and continuously improve how the company serves customers online and in its retail stores.

Check out this 30-minute video of the conversation between Chuck, Apigee's head of business transformation strategy John Rethans, and IDG's Tom Schmidt.

T Mobile

In this video, you'll also be introduced to Apigee Compass, an online tool that helps companies plan and prioritize their digital transformation journey.

 

 

T-Mobile: From IT to Advantage

An interview with the telco’s former chief information officer Gary King

When the U.S. government killed AT&T’s $39 billion bid to swallow up rival T-Mobile in 2012, the would-be target had arrived at a major crossroads.

“Innovation and development had pretty much taken a hiatus,” said Gary King, former T-Mobile executive vice president and chief information officer. “When that merger was not approved, the company really had to rethink the way it went to market and fundamentally change how it addressed its customers.

"Otherwise it was just going to be competing against two big incumbents, and it had been doing that for a number of years without a lot of success.”

The telco responded by rebranding itself as an “uncarrier,” and offered lower prices, contract-free plans, free music streaming, and a host of other features aimed at attracting customers. The need to eliminate customer “pain points” and handle the resultant influx of new customers (T-Mobile’s subscriber based doubled to around 60 million in 2013, King said) required some serious changes in how the company’s IT organization worked.

Speed was key, so gone were the days of large quarterly releases, King said. They were replaced by almost daily implementations of application changes, he said. 

“This fundamentally is the vision of what you want do do when you are rapidly responding to the marketplace,” King said.

Adding to the challenge of transforming IT was the fact that T-Mobile sells through nearly 70,000 outlets—and only 20,000 of those are operated by the company or its MetroPCS unit. 

“A change in an application associated with contracts or data provisioning or with free music streaming … all of those points of presence are potentially impacted," he said. "The ability to rapidly enable testing of those remote systems was also a big component of moving faster and eliminating IT pain points."

For my complete interview with King and discussions with a host of other technology leaders, please check out CIO Upload.

CIO Upload is a podcast series by technology leaders for technology leaders. Apigee chief architect Greg Brail interviews technologists to learn best practices, challenges, and tips for meeting the demands of the evolving digital world.