Modernization Hub

Modernization and Improvement
App Modernization and Migration With APIs  (Cloud Next ’19)

App Modernization and Migration With APIs (Cloud Next ’19)

Good evening, everyone. Thanks for coming over. I hope you’re having
an exciting day today. We understand it’s
been a long one, and we are all very keen to
go and head to the afterparty. So we’ll try and make this one
of the most memorable sessions of the day for you. Throughout the
day, you will have been hearing about
the benefits of Cloud, and how the need for
speed, agility, scale, and ease of deployment is
required in business today. In this session, we are going
to talk about app modernization and app migration
but also link it to how to enhance the end
user experience in the way. Globally, we are seeing
a trend in organizations, where they’re thinking about
the end user experience before they think about the
technologies that are needed to power those experiences. We call this an
outside in thinking. Woolworths is a shining
example of this outside in thinking mindset. Woolworths is the largest
retailer in Australia, and they have been able
to provide their consumers with the seamless omnichannel
experience, irrespective of the channel that they’re
accessing the Woolworths services on, whether
it’s their web app, mobile app, or
even Google Cloud– or Google Home, rather. My name is Parna Bhattacharya. I’ve been with Google for the
last two and a half years, and with Apigee for six
years prior to that. Throughout my journey,
I have played a variety of roles, right
from engineering, to consulting, to leading the
sales engineering team today. The charter of my team is to
accelerate our customer success on the platform and provide them
business value on the platform as soon as possible. I’m thrilled to have me
on stage Joshua Rogers from Woolworths
Josh, over to you. JOSHUA ROGERS: Hello, everybody. I’m Josh Rogers. I am the platform technology
manager at WooliesX. I just started there
about a year ago, and I’m keen to help them
on their cloud journey, and we’re going to go
over some of that today. PARNA BHATTACHARYA: Sure. Thanks, Josh. So let’s quickly
go over the agenda for the day for what we are
going to cover in the next 45 minutes. We’ll start with
the various spots that an organization can
take to move to the cloud and modernize their
technical stack on the way. We’ll talk about some
of the key challenges that we have learned in our
journey with multiple customers globally, and how can APIs
and API management help mitigate some of those
challenges and risk. Josh will then take
over and talk to us about Woolworths’ journey
of providing their consumers with connected
experiences, and then provide specific examples
of how they have modernized their technical
stack and migrated some of the key
workloads to the cloud. We’ll finish the session
with our omnichannel demo and an architecture
associated with it. By the way, Josh and I
both have flown all the way from Australia. And to make the session
more interesting, we decided to share some
Aussie fun facts with you throughout the session,
so pay attention. A quick reminder–
throughout the session, please feel free to ask
questions on the Dory app. Go to the Next app, click
on the session link, and add questions
throughout the session. At the end of the
session, if we have time, we’ll answer some
of those questions. If not, we’ll make sure that
we get to each one of them offline. All right, let’s get started. Any organization needs to
decide their cloud strategy based on multiple
paths that they can take on moving to the cloud. Organizations can decide to
lift and shift their workloads into the cloud and
then modernize it, or they can decide
to modernize on prem and then move to the cloud. Very rarely do we
see organizations just moving to the cloud without
an aspect of modernization associated with it. But any organization
would have to decide one of these paths
based on the workloads that they’re migrating and the
consumers of those workloads. Migration is never easy. It takes time. Sometimes months,
sometimes even years. Irrespective of the path that’s
chosen for migration, APIs and API management can make sure
that the path towards moving to the cloud is made easier. Next, let’s take a look at
some of the common challenges that we have seen our customers
face through the various field engagements we have worked
with the customers globally or the surveys that
we have conducted. The first and foremost challenge
that any organization faces is business continuity. Migrating to the cloud should
not disrupt the existing user experiences that an
organization has, and those can be
external experiences over web or mobile apps. It can be a partner
experience, on even your internal employee apps. That’s the first challenge. The second is, of
course, security. When workloads are
migrated to the cloud, the data invariably
lives in multiple places and are being accessed
through multiple channels. Making sure that this
happens in a secure way, adhering to the compliance
requirement and the best practices that your organization
has set up is vital. The cloud challenges visibility. There are some key questions
that any organization faces during the
migration to the cloud. How’s the traction
of my migration? Which workloads have
migrated to the cloud? Which are still on premise? Are my on premise apps still
getting traffic from consumers, or can I deprecate them
or decommission them? Answers to these questions
are key to take some business decisions in any organization. The fourth challenge
is interoperability. The new or modern apps
which have been replatformed and move to the cloud
many times don’t want to access the legacy
protocols that the legacy apps might expose. Also, the onus of talking to
a different kind of back end, whether it’s modern
or legacy, should not lie with the app developer. The app developer in this
case are our consumers. Because this has made
their apps more complex, they will have to write
conditional code based on whether they are connecting
to a modern app versus a legacy app. So that’s the fourth challenge. The last challenge is
unmanaged services. Moving to the cloud
invariably results into, or most of the time results
into a microservices based architecture. While we understand the
value of microservices based architecture, there might
be unmanaged microservices, which can cause security
challenges, duplication of code, or
unintended behaviors. With me so far? Good. Introducing Apigee– Apigee is
a full lifecycle API management platform. I can talk about Apigee
for the next few hours, but for the purpose
of this section, I’m going to just
restrict myself to the features of
Apigee that will help us in mitigating the risks
that we spoke about in the previous slide. Josh in his section
is going to cover some of the high-level
key features that Woolworths is leveraging
of the platform today. So here, on the
left-hand side, you see the various end
user experiences, which are exposed through
web or mobile channels. These are your end customers. On the right, you’ll
see the back ends or the system of records. These system of records
can be on microservices. It can be a Node.js app. It can be an app on
GKE or even a legacy monolithic application. The biggest challenge that
any app migration faces is the tight coupling
of the user experience with the system of records,
or the exposure layer and the consumption layer. So Apigee provides a layer of
abstraction between these two worlds, ensuring service
connectivity, and making sure that the apps, whether
they are the front end workloads or the
back end workloads, can be migrated without
disrupting the existing user experiences. We spoke about the
security challenge. Apigee can act both as
a security mediation and a security
enforcement clear. So as apps are replatformed
and modernized, the protocols and the
security mechanisms that they leverage might be
different than the legacy ones. The modern apps might use
protocols or mechanisms, like JAR token or OAuth,
and the legacy apps might be leveraging basic
authentication or SAML. Apigee provides uniformity
by exposing a single security mechanism to the
apps via mediating the credentials between the
legacy and the modern apps. Apigee can also provide
security checks or enforcements, like regex checks or data
loss prevention checks when the on premise workloads
are calling workloads on the cloud. The third aspect was visibility. Because here Apigee acts as a
facade between the on premises and the cloud workloads, it
has the required visibility on how the migration
is progressing. What’s the traction
on migration? And it can give us
the data, like which are the APIs or
API products that are leveraging newer back ends? Which are the ones who are
leveraging legacy back ends? Have all the traffic
moved to the new back ends so that I can decommission
my legacy applications? This allows the platform
and the product owners to take business-driven
decisions that are needed for any organization. The fourth challenge
that we spoke about was interoperability. The reality is that
not all apps can be migrated at once,
which means that there’ll be apps which have been
replatformed and modernized and move to cloud which still
needs to talk to legacy back ends. Or there might be newer apps
that are being written today, and they might have
to talk to both legacy and the new back ends. Apigee helps by
providing an API facade which can do the
required transformation, like SOAP to REST. And it takes out the necessity
for the app developers of modern apps to
have conditional code or download specific
libraries to talk to, let’s say, a SOAP back end. Moving on, the last one
was service management. Lift, shift, and
modernize is a common way of migrating to the cloud, and
many organizations leverage microservices,
often on Kubernetes, to achieve the same. As I said, while we are
aware of the benefits of the microservices
driven architecture, the challenge is an
explosion of microservices in an organization. We need the right
security and visibility to make sure that those
microservices are adopted across the organization to
prevent any duplication of code or security loopholes. Istio is a common
way to manage this, which acts as a service mesh. Apigee adds an additional
API management layer by providing security
protocols, like OAuth or additional analytics. For organizations who
are not leveraging Istio or microgateway,
Apigee’s microgateway provides similar capabilities. With that, I come to the
end of the first section. So we spoke about the various
parts towards migration, the top five challenges
that organizations face on modernizing and
migrating to the cloud, and finally, we spoke about
how can APIs and API management help mitigate some
of those risks? Now, before handing
over to Josh, I’m going to give you the first
Aussie fun fact of the day. Australia is an island nation. It has more than 10,000 beaches. So if you were to visit
one new beach every day, it’s going to take you 27
years to visit all of them. Who wants to get started? Thank you. JOSHUA ROGERS: Thank you, Parna. [APPLAUSE] Thanks. All right, so now I’m going to
introduce you to Woolworths. Woolworths is a
customer of apologies. Woolworths was founded
in Australia in 1924. They started as a small location
called Woolworths Stupendous Bargain Basement. And as they continued
to grow and spread throughout Australia, they
developed a nationwide presence around 1960. They were soon on their way
to becoming a household name. Come February 1998, they
launched Home Shop, which is e-commerce for groceries. And it was one of the
first in the world to offer groceries fresh to
your door after ordering online. There was a couple
other group businesses who also endeavored online
during this time as well. Woolworths is a combination of
a lot of smaller businesses, and each individual business
had a concentrated effort to establish an online
presence individually. So as these businesses
continued to evolve and new technology
becomes available, our websites that were once
hosted in a private data center were lacking access
to the technologies, and we were fastly
getting outpaced. So with that developed
an opportunity for us to migrate into the cloud. Not only did we want
to lift and shift, like Parna had spoken
to before, but we also wanted to modernize it. And it’s not your regular
digital transformation. It’s also a supermarket
at nature trying to enter a digital market. So in order for us to accomplish
some of these digital feats, the Woolworths group started
combining a few of our efforts and establishing a holistic
customer experience by way of WooliesX. WooliesX is a combination
of engineering and business professionals that concentrate
on the customer experience at the forefront of every
decision that’s made. You can see here we have
over 500 team members and 400 customer service agents
working to make sure that our team understands
the needs of our customers. Things that we’ve been able to
accomplish in a few short years since this
organization was formed are we are up to 11.5
million rewards members. So to give you a little context,
there’s only 24 million people living in Australia, so we’re
nearly half of the population is a rewards member. Another quick fact is there’s
only about 12,000 households, or sorry, 12 million
households in Australia, so we’re 1 for 1 in every
household, not particularly every household,
but numbers wise. Some other things to note–
we do over $2 billion in transactions. And that’s quite
a big number when we’re talking about
a supermarket that’s moving online. So how did we get
started on Apigee? We had the need to connect
our consumer applications with some back end services
that were not particularly owned by us. We had applications
that need to connect to third-party
services, and we also had employee apps that need
to connect to our HR services. We started with two businesses,
six developers, built 15 APIs, and was handling around 45
transactions per second. Apigee helped to streamline
the developer experience. A couple of the key
features that Parna wasn’t able to speak into
are the Developer Portal. The Developer Portal allows
you to create an API key and understand
the contracts that are established between our
APIs and you as the consumer. The consumer doesn’t have
to be an internal employee, it can also be an
external consumer. And that’s one of
the things that we want to make sure
that people understand is anything that’s good enough
for your internal teams should be provided as good or even
better for your external. And similarly
anything that you’re going to deliver high quality
for your external consumers, you should treat your
developers with the same level of establishment. Some other things that really
benefit us are permissions. The granularity of permissions
on the Apigee platform allow us to get down to
delivery of the application to production, traceability
of those transactions during live messaging,
as well as visibility into analytics and controls
that help safeguard our APIs. API abuse prevention in
the way of Apigee’s sense allows us to capitalize on
Apigee’s AI and ML models to identify anomalies and
any other malicious behavior, and stop it before it
gets to our systems. And this is a key thing
for us to make sure that our customers
themselves are getting a consistent experience, no
matter who is being malicious on our network. And additionally,
API Monitoring allows us to make sure that
our traffic patterns are where we expect them to be. If we see an increase of
500s over a period of time, we can alert ourselves
over email, Slack, or even a customized web hook. And those web hooks can be
very powerful to integrate with any of the systems that are
not on boarded into the Apigee platform. One of the other key things
that I want to mention is Parna, as well as
other of our accounts and support engagements at
Apigee, have been along with us every step of the way and have
been critical for our success on the platform. So with our success, we unlock
new business opportunities. Some of these are
business ventures that capitalize on
just an abstraction between the customer and
our back end services and don’t offer anything
in the way of really adopting or spreading
data between the services. Other services are
fully connected into each other via data. So our insurance
service, our credit cards and financial services
and gift cards, those are all services
that are brand new and we’re trying to
explore as a company. Later on, we’ll build
up the technologies to establish them ourselves. But the presence on
Apigee will not change. We’ll try and keep that contract
as consistent as possible. Scan and Go, which is a
new, innovative customer experience for
our stores, allows customers to walk in,
find the goods they need, scan them with their phone,
and complete the checkout process themselves. They don’t have to walk
through our checkout lines or deal with any
of our employees. They can just create their own
experience within our stores. Woolworths online also reaches
almost half a million customers actively. And we run our mobile
applications through Apigee to make sure that,
again, our customer’s getting a consistent
experience when integrating with our services. And then down on the bottom
right, you see rewards. Rewards is a critical component
to collecting that customer experience data and making sure
that we can consume it and then respond to it. We can take the rewards
data and integrate it with every single one
of our services because of the availability
that we have on Apigee. So we continue to grow. We now have reached over
10 businesses internally. We have more than 18
developers actively developing on APIs, the evolution,
the modernization, the governance of those APIs. We’re trying to
keep them up to date and making sure that all
1,000 of our available APIs are up to the same
standard as we want. And now we transact
over 480 times a second on all of our APIs. And that’s something that we’ve
peaked quite a ways higher, but it is without a hitch. So as with most growth, there
becomes a few challenges. There’s an evolution. New opportunities arise. And I’ll talk to you about
one of our opportunities to migrate from a database as
a service to GCP Cloud SQL. All of our back end
ancillary systems deliver a large parcel of
data into a blob storage, and then we utilize triggers
to transact that data and load it into our databases. Apigee acts as an
abstraction layer. So during the development
of Scan and Go, our product that I
was telling you about, we needed to move the data from
our database as the service over to Cloud SQL. Our database as a service
was operating on an account that we didn’t have
full control over. We didn’t have the
ability to react or permiss any
additional resources. So in order for us to
continue to grow and expand our operations, we need to take
that control into ourselves. So we utilized Apigee to
continue that contract to our customers while we
make those back end changes. So a lot of that learning
that we had to do is still with a very
new organization. We’re only a year and a
half in at this point. And we were able to do it
with the support of Parna and the team at Apigee
to redevelop our Lotus scripts within Google. We were able to move the
data over preemptively. We’re also able to test and go
through all of the scenarios to make sure that
our applications are going to respond
to the new data store. And we were able to do it
with only a 30 minute window of execution. Special thanks to Terry,
Shyam, Madhan, our API team, our business teams, are
QAs, and the support staff who made sure that
we were diligent about every aspect
of this migration. So now, we’ll transition
to another Aussie fun fact. And we’ve added on this slide
the crest from Australia. A good fact about the kangaroo
and the emu are they cannot work backwards. And so there’s a bit of
meaning as to why they face each other on the crest. So now I’d like to
introduce you to Olive. Olive is our virtual
assistant that we’re developing outside of our
cognitive technology services team. Olive is able to analyze
customer inquiries, align their intents with
actionable workflows, and then take that data, package
it up, and present it back to the consumers in
a consumable way. We have features like our store
locator and hours of operation. We also have features
to modify your lists, manage your shopping lists,
and answer any frequently asked questions that you might have. So what I’ll talk to you
through is a quick demo of our Olive platform. So I’m going to focus on
our Google Home integration. GOOGLE ASSISTANT:
The mike’s back on. JOSHUA ROGERS: Sorry
for the loudness. All right, so, OK, Google,
talk to Woolworths. GOOGLE ASSISTANT: Sure. Let’s get Woolworth’s. Welcome to Woolies. How can I help you today? JOSHUA ROGERS: What’s
my nearest store? GOOGLE ASSISTANT: To find the
address for your local store, I’ll just need to get your
current location from Google. Is that OK? JOSHUA ROGERS: Yes. GOOGLE ASSISTANT: The address
for Woolworths Wagga Wagga is 87 Baylis Street, Wagga
Wagga, New South Wales, 2650. Is there anything else? JOSHUA ROGERS: What
time do they open? GOOGLE ASSISTANT:
Woolworth’s Wagga Wagga at 87 Baylis Street is
open today from 7:00 AM until 10:00 PM. Is there anything else? JOSHUA ROGERS: What’s
on my shopping list? GOOGLE ASSISTANT: Your
shopping list is empty. Would you like to add something? JOSHUA ROGERS: Add milk
to my shopping list. GOOGLE ASSISTANT: I added milk. Would you like to add
another item to your list? JOSHUA ROGERS: Wouldn’t be
Aussie without Vegemite. GOOGLE ASSISTANT:
I added Vegemite. Would you like to add
another item to your list? JOSHUA ROGERS: Some Tim Tams. GOOGLE ASSISTANT:
I added symptoms. Would you like to add
another item to your list? JOSHUA ROGERS: Doesn’t
understand my American accent. Sorry. No. GOOGLE ASSISTANT: Sorry, would
you like to add another item? JOSHUA ROGERS: No. GOOGLE ASSISTANT: Can I
help with something else? JOSHUA ROGERS: No. GOOGLE ASSISTANT: Thanks for
speaking with the fresh food people. Goodbye. JOSHUA ROGERS: So there’s
a quick introduction to our automated services
that we’re trying to develop. And the key factor there is
we have back end services that have all the data that the
customers want to have access to, and they want
to be comfortable accessing that data. They want to be
able to interface with our business in
the ways that they’re most easily available to them. So one of the things
that we did there was talk about
our shopping list. And so I’ll switch over
to my laptop, which I’ll show you our website. And on our website,
I’ve already logged in. I can just click on my
lists, go to my Google Home, and you can see I added
symptoms to my shopping list. [LAUGHTER] I’ll just go ahead and
remove that for us. The other thing that we have
integrated into our website is the ease to take
something that was spoken, and then turn it into a
search just by clicking on it. You can scroll through the
results, find the one you want, quickly add it to
the cart, and then continue with the next
step, your next item, and do the same. We’ll go with the
Drought Relief milk– help out the farmers– and then continue the
checkout process from there. Thanks. Switch back to the slides. And so how were we able
to accomplish this? We started with a
very simple task, to make sure that we take a real
customer impacting event, as well as a real business
impacting event, and we married them together. Our customers call
up our Customer Hub, and they want to know specific
information, information that’s very readily available, but
they don’t have any other way to get it. Calling up our Customer
Hub takes up time. There’s a lot of
other activities that our Customer
Hub endeavors in that take up a lot more time
than they probably need to. So we utilize our voice
integrated with Dialogflow. We work with our applications
that are hosted within GKE. We then operate through Apigee
to our back end services to find the data that we need to
deliver the experience that we want. We funnel it back
into our applications in GKE, which prepares it
for delivery to the customer. Our chatbot is able to connect
to our customers via Hangouts, a chatbot virtual
assistant on our website. You can call us up on the IVR or
speak to us on the Google Home. And we utilize the
same architecture, oversimplified for this
illustration, for all of it. And that allows us
to expand even more into answering and
connecting with our customers in a digital way. We want to make sure that
it’s not just our Woolworths online experience
that they have access to, but also our BWS, our
Big W, Our Dan Murphy’s, our money and
financial services, and we want them to be
comfortable and connect to us in any way that they would
like, over Facebook Messenger, Alexas, Homes, digital
assistants of any kind. And I think that that
brings us to the end. So we can ask any questions
if you guys have any. [APPLAUSE] Thank you. PARNA BHATTACHARYA: There are
few questions on the Dory. But before that, if anybody
has a live question, we can take that first. Couple of questions
on the Dory about, could we get access to
the recorded presentation? Absolutely. I think it will be added to
YouTube in the next few weeks. JOSHUA ROGERS: The
slides are also going to be prepared as a
PDF and available as well. PARNA BHATTACHARYA: Yeah. All right, the next one–
could the Apigee API be used for monitoring service– service management, incident
management escalations? So Apigee acts as
a abstraction layer of facade, which
means that Apigee can be leveraged for monitoring
your APIs, SLAs and SLOs. And, in fact, that’s
something which Woolworths uses significantly. Josh, you want to share your
experience with API Monitoring? JOSHUA ROGERS: Yeah, so we
utilize API Monitoring to make sure that our back end
services understand what scale of traffic is
coming through the platform. When we’re caching on the front
end or within the Apigee layer, it’s not always
clear, a small change that introduces
entropy or a dynamicity into the requests,
how much of an effect that might have if it’s not
able to cache it on that layer. So we want to make sure that
we’re very cognizant of how much traffic is
flowing through Apigee, and we utilize our learning
and different dynamics– there’s multiple different
dimensions available to measure– to alert us of any changes
in the transactions as well. PARNA BHATTACHARYA: Absolutely. Question from Allstate. A few likes and
upvotes for that one. Do you think– this
is for you, Josh. Do you think the adoption
of Apigee and API management and productionization APIs by
Woolies helped grow or increase revenue? If yes, can you please
elaborate on that. JOSHUA ROGERS: Yeah,
absolutely because we want to make sure that we
have that consistent customer experience across all
of our businesses. And what that’s going
to do is generate a bond with our customer. It’s going to set
some expectations, and they’re going
to feel comfortable transacting with us. So the immediate
revenue increases to make it available
for our customers to shop or interact
with our services on a variety of platforms. But then the long-term increase
of maintaining that customer retention is also beneficial. PARNA BHATTACHARYA: Sure. Thanks, Josh. The next one, again, for you,
somebody from Delta Airlines, again, upvoted a few times. Could you talk about
the API development roadmap used in WooliesX? How the APIs were identified? Was that a business
driven top down? Was it a project driven
bottom up approach to develop and deliver APIs? JOSHUA ROGERS: Yeah, absolutely. So the necessity for
data to become available should be the first thing
that you consider when you’re developing your services. It’s not necessarily the
data that’s valuable to you, but the data available for other
services to integrate with you. Especially in a distributed
microservice world, you want to make
sure that you’re not having to modify the
contracts to provide the data that somebody might
need to make a business transaction possible. One of the situations
that we’ve ran into while establishing
a virtual assistant was we didn’t necessarily
have access to the data that we wanted to improve
the customer experience, things like, what time
will my order be delivered? So we’re constantly working
on enabling integration and putting that
at the forefront of a lot of the
business decisions that we make when first
designing those services. PARNA BHATTACHARYA: Yeah, it’s
always a combination of both, but understanding who are
the consumers of your APIs, and making sure that you
identify and then work backwards from there is
usually a good recipe. JOSHUA ROGERS: Yeah, absolutely. PARNA BHATTACHARYA: The next
one from Optimals, again, a lot of upvotes for that. How do you data
mine bad consumers? What advice would you give to
a government entity looking to leverage Apigee? First of all, leverage
Apigee, absolutely. And if you have questions, come
to the Apigee booth downstairs. But handing it over to Josh. How to data mine bad consumers. JOSHUA ROGERS: So you repeat
the question one more time? PARNA BHATTACHARYA: How do
the data mine bad consumers? I guess this is from an
external end user perspective, from our Sense, I
guess, about detection. JOSHUA ROGERS: Right, so
Apigee Sense provides us a bit of the bad actor
detection, and we’re actually– it doesn’t ever reach
our systems themselves. We’re able to get a report
on what transactions have been blocked on the Apigee
layer, and then react to those. If we wanted to
try and data mine to make sure that we’re
analyzing the traffic patterns or the opportunities
that people potentially might explore with other
APIs that don’t process through Apigee, there
are opportunities for us to go back and analyze those
reports to see which ones are actively being
actioned, as well as any of the traffic that
comes all the way through. Apigee provides an
opportunity for us to analyze the data themselves,
or sorry, data from those transactions as well. So if we do see something that
may have made it through Apigee Sense, we’re still able to
go back and try and identify some of those traffic
patterns and utilize our own defenses at that point. PARNA BHATTACHARYA:
Yeah, and especially in the case of
Woolworths, we have seen how geolocation, there
is the originating traffic? That has helped quite a bit. Like, you don’t expect
people from Asian countries to put online requests on
Woolworths in Australia. So geolocation, again,
a part of Apigee Sense, has helped quite a bit. And again, we do have a
lot of government entities who are Apigee’s customers. A lot of security patterns that
we have been able to establish, so definitely worth
a chat to whoever has posted that question. Quickly moving on,
we do have time, so I guess we are doing fine. In your experience, what are
your most critical patterns and antipatterns for
API driven development? JOSHUA ROGERS: Yeah, I think I
touched on that a bit earlier. And you never know
the data that’s going to be consumed
until you go to utilize it and it’s not there. You want to make
sure that you’re trying to identify the best ways
to vent the data in a protected manner, but make it available
for internal consumers, and in some cases, external
consumers to identify. The other thing is to make
sure that your developers know very well how to version. An API forms a contract
between consumers and services. And if we don’t
version it properly, features or data might not
be available the next time they call your service. And we want to make
sure that, internally, every contract that
we commit to maintains the same level of inputs,
outputs, and data formats as we once committed to all the
way through the lifecycle. Which leads me to
the next point, which is know and establish
a deprecation policy. Make sure that before you put
something into production, you know exactly how you’re
going to go about taking it out of production, as well, when
the validity or lifecycle of that service is over. I think those would be the
three things that I would– PARNA BHATTACHARYA: Absolutely. And again, Apigee has
published a book recently, and it’s technology
agnostics on antipatterns and best practices around APIs. So maybe I’ll put a link into
the Dory question later on. A question that’s
getting a lot of votes is, how many poisonous
snakes are in Australia? JOSHUA ROGERS: There’s a ton of
poisonous snakes in Australia. PARNA BHATTACHARYA: A lot. I think this is time for
both Josh and I to also she had a secret. Both of us are kind
of fake Australians. I’m an Indian, and Josh
is an American, but, yeah. But loads, right? JOSHUA ROGERS: Yeah, absolutely. There’s a ton of creatures
out to get you in Australia. PARNA BHATTACHARYA:
How does Apigee work with multi-cloud environments? This is a good question–
a few comments there. Do you have a
federated API gateway? That’s a great question. Yes. Apigee Hybrid is
something which we are announcing as part of Next. We would be able to provide
APIs gateways, which can run near to your data
center in multiple locations with a single control plane. To know more, please do
visit the Apigee board in the expo area. But a short answer is yes. Even with multi-cloud,
I think, as it was mentioned in the
keynote today, we do know that most organizations
will have multiple clouds, just like Woolworths. And we do have the ability to
work across multiple clouds with our Hybrid offering. It’s a good question there. Thank you. Oh, somebody put
a question saying, we have multiple
cloud situations, and so far, Apigee
has worked well. So thanks, Glenn, for
putting the comment there. We do have time for a few more. Where do your Apigee alerts
get routed to in Woolworths? Does it use web hooks
to call pager duty? I think we are getting
deep into the dance now. Or send an email directly? Or does it feed into a bigger
system for alert management? JOSHUA ROGERS: So Apigee
Sense itself provides you the– or sorry, not Sense. API Monitoring, right? PARNA BHATTACHARYA:
Monitoring, yes. JOSHUA ROGERS: API
Monitoring provides you the opportunity to specify email
address, Slack integration, and– PARNA BHATTACHARYA: Web hooks. JOSHUA ROGERS: –web hooks, as
well as pager duty integration natively. So you can work your
alerts into those systems. Things that I would
utilize web hooks for would be executing maybe
a service Wow incident or some other
incident managements to try and get you a bit more
of a record on your incident management systems that
Apigee can tie into. PARNA BHATTACHARYA: Sure. Another question from
Delta Airlines Rajeev. Was your API development
centralized or distributed? A great question again. How did the org adopt to APIs? Was there a separate
governance team to build and enforce standards? JOSHUA ROGERS: So the
question around centralization versus distribution– we utilized a central
team structure. And my developers
themselves are actually integrated into the squads. So we utilized the central team
to form a community around APIs and best practices,
governance, and then also to share knowledge
around what has worked and what has caused challenges. But the developers
themselves actually operate strictly
within the businesses, so it is quite the decentralized
model in that sense. PARNA BHATTACHARYA: Yeah. And usually, our recommendation
when we work with customers is to start maybe with
a centralized team to ensure that the best
practices and the governance is being put in place. And then as you mature and
the API program matures, it makes sense to have
a decentralized team. And we call it governance
with a small g, which means that the idea
is to enable the team to innovate and
leverage the platform, rather than act as
another gate there. But, yes, absolutely. I think we have seen multiple
customers follow the same route that Woolworths
has done through. Can you speak to Apigee
deployment model in use at Woolworths? Are you using Apache
cloud on prem or hybrid? JOSHUA ROGERS: So right
now, we operate solely on cloud services within Apigee. That said, we are working with
the engineering teams at Apigee to be one of the early
adopters of the Hybrid Cloud, looking to see how it fits into
our current cloud operations, and permissions
models, and structures. So the way that we organize
our services within GCP is going to be
different than the way that we organize
with within Azure, and we want to work
with Apigee to make sure that it’s comfortable
when we move Apigee into those different
cloud providers. And so I would say that
primarily on cloud, we utilize the tools
that are provided for us. And then in the
future, we’re going to be utilizing more
of a CI/CD delivery model to each individual pod
that we deploy for Apigee. PARNA BHATTACHARYA: Sure. Another question
on, can you let us know what sort of API
versioning features are provided and leveraged? So this is part of the
API design, it says. JOSHUA ROGERS: Yeah. And what Apigee
provides you with is a few different environments
that you can set up to stage any of your
production changes before you get them all the
way through your pipelines to production. Within each stage,
you’re getting access to every single version. A version is actually, in Apigee
Sense, a set of artifacts. And once a set of artifacts has
been uploaded to the platform, it’s available to be made
into a production service or made available on any
of those environments. And it’s very quickly
to demote or promote one of those versions
into an operation. The actual management of
the versioning of the API should be done within
your code, and then delivered to the system in a way
that allows you to manage which ones are currently in
production without affecting any of the other deployments
that you’ve already made. PARNA BHATTACHARYA: Maybe
this is the last question that we take now. JOSHUA ROGERS: Yeah,
we’re running up on time. PARNA BHATTACHARYA:
Yeah, we will be running out of time soon. How do you engage with
external app developers? And how did you achieve better
engagement and participation? Again, a key part
of any API program is engaging the app developers,
both internal and external. JOSHUA ROGERS: So each one of
our external app developers goes through our
business-to-business team. And the
business-to-business team has a core function to
establish that relationship. But as you can
imagine, the developers are not part of that
transaction usually, so a lot of our documentation
is available via the developer portal for the APIs
that we make available for our external consumers. The adoption of it,
though, is driven by an active conversation
that we maintain between our developers,
our external developers and our internal developers. We provide an
opportunity for them to get together and actually
discuss any of the challenges that the external consumer
might come across, and then also work to make
sure that we address them. PARNA BHATTACHARYA: Yeah, and
we are seeing organizations have a specific rule
around evangelism, both internal and external. And hackathons play
an important role to make sure that your APIs
are well-known internally, and even expose it to
the external consumers. So even Slack hackathons
actually help. All right, with that, thank
you, again, for staying back. Let’s head to the afterparty. Thank you very much. [APPLAUSE] [MUSIC PLAYING]

Leave a Reply

Your email address will not be published. Required fields are marked *