Practical Applications of Microservices for Ecommerce
•Als PPTX, PDF herunterladen•
1 gefällt mir•180 views
A deep dive into specific ways brands and retailers like you can leverage microservices to transform your digital experience and deliver true commerce anywhere. You’ll learn how microservices can help you: - Bypass 4 key limitations of monolithic platforms - Beat your release cycle - Make better merchandising decisions based on real-time data - Integrate with emerging touchpoints such as AI and chatbots in rapid time - Create new customer acquisition opportunities
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Practical Applications of Microservices for Ecommerce
Ähnlich wie Practical Applications of Microservices for Ecommerce (20)
Mehr von Skava
Mehr von Skava (9)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Practical Applications of Microservices for Ecommerce
- 1. Practical Applications of Microservices for Ecommerce
- 2. Linda Bustos director of digital experience strategy Your presenter
- 10. End game: become a high-performing organization •Enable development teams to work fast and independently •Scale with business growth efficiently •Build a resilient infrastructure
- 11. 4 key limitations of monolithic platforms: •Can’t get ahead of the release cycle •Difficult to extend to new touchpoints •Can’t choose the “best tools for the job” •Can’t run services in parallel
- 12. Beat the release cycle
- 20. Extend to new touchpoints
- 22. Use only the “parts” you need
- 29. Use the best tool for the job
- 30. Structured vs unstructured data
- 43. Run services in parallel
- 44. Parallel microservices: B2C / B2B
- 46. Parallel microservices: A/B testing 46
- 47. How can Skava helpyou?
- 48. Skava Commerce UNLEASH E-COMMERCE OUT OF THE BOX BUILDYOUR OWN PLATFORMTM ENHANCE YOUR EXISTING DIGITAL EXPERIENCES Everything you need to launch a cutting edge e-commerce solution out of the box. Use as a foundation to build your own digital future. Choose the microservices and digital applications you need.
- 49. Skava Commerce is built for the complex requirements of large enterprises. It has wide range of deployment models and a modular architectural approach suitable for incremental delivery and platform migration. - GARTNER MAGIC QUADRANT FOR DIGITAL COMMERCE, 2018
- 51. 5 THANK YOU!
Hinweis der Redaktion
- Hello, thank you for joining us today I’m Linda Bustos, the director of digital experience strategy here at Skava, and I’ll be with you for the next hour talking about practical applications of microservices – we’ve covered a lot of topics here at Skava on what microservices are and how they help, but this session really takes a deeper look at what microservices really mean for you in terms of use cases, how they specifically help you work around real problems of monolithic architecture and what real companies are doing to create new customer acquisition opportunities and more.
- Thank you Hassina, and thank you everyone for joining us today. Let’s start with a quick refresher on why microservices are gaining traction with some of the world’s top digital retailers such as Best Buy, Amazon, Staples, Nike and Urban Outfitters
- Despite the luxury of robust and highly customized commerce platforms along with top of the line IT groups, these big brands move away from traditional, monolithic architecture in order to be more agile, innovative and disruptive. The big challenge with monolithic legacy platforms is how they’re built. Monolith literally means “one stone,” or one solid piece and for software this means all aspects of your platform share a single code base and are tightly coupled to each other. So it’s kind of like a Jenga tower, if you want to make a change or extend the tower by pulling on one piece, you have the potential to disturb other pieces. As you keep making changes and evolving your platform, you end up with instability and the risk just increases that the entire platform will eventually go down. And the block rarely falls over with digital commerce because you’ll set out on a replatforming project before you get too rickety, which is a massive project that costs a lot of money, takes a lot of time and puts you right back on another monolithic platform to start the cycle again.
- Another way to think about it is the pick up sticks game, this really illustrates the dependencies that can exist between pieces of your system. So if you want to move one piece – add your custom features, or get it into a new touchpoint, et cetera, developers aren’t totally sure what other components this can disturb until you actually get coding, so that takes a lot of regression testing and diligence before code can move to production. You have to test the ENTIRE system, because of these interdependencies.
- In contrast, microservices architecture is an answer to the challenges of monolithic architecture. Think of them as discrete building blocks, each piece of business functionality is decoupled and containerized, and any extensions and updates to these individual pieces of your solution won’t affect the other pieces. Virtually any business function can be blocked off as a microservice and decoupled from the rest of your system so it can be independently deployed, scaled and modified. This also really simplifies upgrades, because instead of a full platform upgrade because, for example, you want enhanced merchandising capabilities, you’re not looking at a rip and replace project which often comes with the need to rebuild all your other customizations in a new system.
- And this allows smaller development teams to work independently and release on their own schedules because any changes made won’t disturb other services’ code. So the areas of your business that you want to iterate rapidly and cleanly can accelerate.
- It’s also important to note that microservices are API-driven, therefore they can be deployed alongside the monolith even if you’re in a position where you can’t migrate fully off your legacy environment. So you can use them to work around your pain points without doing a “big bang” replatforming project. It also allows you to tackle areas of your business that are higher priority, such as services that benefit from rapid development, or that have unique requirements that your existing platform doesn’t support, or that have immediate need to extend to new touchpoints or scale.
- And a typical migration away from a monolith will start with what’s referred to as a “strangler pattern” – as aggressive as that might sound it’s very gentle, it’s starting off with a single or handful of microservices to support what you’re trying to do with the goal to ultimately displace the legacy system with a full modular environment. And you can go at your own pace.
- So why is API-driven, modular architecture really getting the attention that it is from analysts, IT leaders and top brands? Ultimately the end game is to become a high performing organization where Developers can work independently, truly embrace methodologies such as DevOps that support rapid development Your business can scale and innovate the most efficient way possible And finally be super resilient so rapid changes don’t interrupt the customer experience and you keep your IT talent happy and less stressed out than they have to be isolated failures shouldn’t cause system-wide disruption And becoming a high performing organization doesn’t just help IT but also contributes to revenue and customer experience.
- Alright. So we’re going to get more granular and practical now – I’m going to walk through examples of how microservices can help you: Get ahead of your release cycle Extend to new touchpoints rapidly and efficiently with less risk Choose the “best tools for the job” and more specifically we’re going to talk about the flexibility to choose the right databases for the job And finally why running services in parallel – more than one version of a microservice - can be a real advantage.
- If you’re on a traditional enterprise monolith, you know – release cycles may happen monthly, quarterly and in some cases semi annually, and that forces IT to be very disciplined in what goes into the release, and if you’re on the business side you’re familiar with waiting or having your wish list items kiboshed. It can be difficult to get ideas off the whiteboard and into production. You also have the challenge of periods of code freeze, such as the holidays or whatever key seasonal events you have where you can’t work on anything new. But imagine if you could bypass this and give critical services their own release cycle. A prime example of this is the promotions engine.
- It’s common in retail, especially for large retailers to plan promotions far in advance, and of course there’s reasons for that, forecasts are made by merchandisers based on last year’s data, or even gut feeling, but that strategy leaves money on the table because real-time conditions and customer behavior rarely match up to these forecasts or even inventory planning. For example, if you’re in charge of online P&L, and if you’re having a soft season, say it’s been unseasonably warm this year and you have excess inventory of puffer coats you want to blow them out at deep discounts earlier than anticipated, or risk being stuck with unsellable product You want flexibility with promotions and the ability to be responsive and make real-time merchandising decisions, and not have to deal with “hey, we can’t model this promotion and test it across the system with alllll the other stuff we’ve got going on.”
- Responsive merchandising allows you to do such things as extend a sale beyond it’s planned end date, for example
- Or bump up a discount to a better deal.
- Or respond to competitors’ moves. If your main competitor drops a pop-up sale or is killing your shipping offer or anything that may threaten your sles, an independent promotions engine allos you to set up, test and deploy within minutes or hours. Some business users try to cheat the release cycle with workarounds that haven’t been properly QA’d but microservices take that behavior off the table.
- You can also be super responsive to mistakes – so here’s an example of a missed opportunity – the “we’re sorry” email has no remedy, no call to action that could generate revenue and goodwill. Now with very responsive systems, this brand could actually reschedule the sale and just make it so, versus creating the burden of the customer having to remember about the sale, or for the email marketing group to send a new announcement again tomorrow because we know customers aren’t going to remember to “check back” later.
- For other site issues like “hey, we’re sorry our site went down” you can create a brand new sale and promo code as quickly as you can whip up email creative and redeem the situation.
- You can also evolve your promotions engine to accommodate more advanced promotion types. For example this is a promotion tied to a specific payment method, the store-issued, branded credit card. Guaranteed this doesn’t come out of the box with an enterprise monolith and took a lot of custom coding. Complex use cases like this are a lot easier to model when you’re working within a smaller, independent application. Your promotions engine can evolve over time like a lean startup, adding features in an agile way and integrating with in-store systems and mobile apps as well.
- And speaking of extending your functionality – how about dem new touchpoints? And I’m not just talking about mobile and in-store, there are a number of very interesting integrations retailers are doing these days, I’ll share a few examples in a moment…
- But first – let’s address headless commerce, which is really the first step towards API-driven commerce. Decoupling the front end from the back end of your commerce platform allows front end developers to push changes and extend UI into new touchpoints very well, essentially the front end becomes like a microservice, but the challenge when the back end remains monolithic and tightly coupled means your commerce capabilities still don’t extend to new devices and contexts very easily. This is why something as simple as putting a buy button in a lookbook or within a blog post isn’t so easy even with an A-Class content management system powering the UI. So think of microservices as advanced headless or headless on steroids in the sense that you can take any touchpoint or experience and connect it directly to commerce features and functionality, you can make new experiences natively transactional, or use only the features and data you need, rather than hardwire to the entire kit and caboodle of your platform, start messing with your core code, require all the testing, and if you want to remove something trying to undo all that work.
- So you can use only the parts you need with microservices, for example an AI-driven chatbot may only need access to account details and history, and the order management system – depending on what you want this experience to do. Later down the line you might want to incorporate checkout capabilities if the pilot is successful and there’s demand for iteration on the project. The experience doesn’t need to connect to other components of your system, and will never interfere with them, unlike when you’re trying to work with a monolithic clump of code.
- Interestingly enough Best Buy Canada recently launched a project like this – an integration with Google Assistant. And this is what I mean buy omnichannel goes way beyond just digital, physical, mobile but incorporates things like AI-driven chatbots and third party devices and their platforms.
- With this integration you as a customer can voice-search the catalog, browse personalized deals, search products, ask questions, check store availability and reserve items in store. Here Best Buy has built a minimum viable product connecting Google Assistant with its APIs to get the data needed in the format needed. If this is a success, the project can keep evolving like a lean startup, or be quietly retired without having to be unhooked from a monolith if it doesn’t gain traction.
- A very early adopter of API strategy is Walgreens. Their prescription refills API connects to many 3rd party health and wellness apps, facilitating native transactions and providing both developers with a monetization opportunity and Walgreens with a new customer acquisition channel without the overhead of building its own apps and trying to get customers to remember to use them.
- The native transactional capability is key – it takes all the friction out of being redirected to Walgreens.com. A 3rd party prescription is refilled every second through these partnered apps. And best of all, because the refills service can scale independently, this volume doesn’t slow down the entire platform and Walgreens can throttle server capacity to the services that need them, versus vertically scaling its entire monolith to handle a new touchpoint.
- Walgreens also does a similar thing with its Balance® Rewards program. Customers can earn rewards points for using popular fitness trackers such as the My Fitness Pal app and fitbit devices. More than 2 billion points have been earned by over 800 thousand users. Another very creative success.
- And the same thing with photo printing services, the API extends to popular photo apps, so Walgreens doesn’t have to build and market these utilities and users don’t have to leave their favorite apps to transact.
- Alright, let’s move on to a bit of a technical discussion. Microservices let you choose the right tool for the job and this does include using the programming languages you want if you’re building your own microservices, but even more importantly it allows you to use the right database structure for different services.
- OK first let’s talk about structured and unstructured data – both are very important to modern digital commerce. Monolithic platforms sit on top of monolithic databases which means the entire platform will run on either a relational database – also known popularly as SQL database – or a NoSQL database which is a newer style and is far less common. All of the big enterprise solutions use SQL and that’s great for structured data, where everything fits within tables and rows like a massive spreadsheet.Things like first name, last name, transactional data, order management numbers and so on. But modern commerce also needs to work with unstructured data such as images, video, pdfs/downloadable guides, social and user-generated content, blog posts, product reviews - even clickstream data, call center logs – this is all chaotic unstructured data that doesn’t fit neatly into a matrix of tables and rows. This type of data is best handled with a NoSQL database that doesn’t rely on tables and rows and structured query language. As we move towards hyperpersonalization and AI-driven commerce unstructured data will become even more important, so the flexibility to use NoSQL database such as MongoDB for services like personalization, customer reviews, catalogs and merchandising is a huge advantage. Services like cart and checkout, inventory, and order management are better suited to SQL so you can have the best of both worlds.
- So what does this translate into. Let’s take catalogs. With SQL database, the schema is predefined before the platform is even built. Schema is the organization of all the tables and what goes in the tables and how they all related to each other. For big applications this gets really complex. If you want to add new product types and attributes, you have to essentially remodel your schema and that takes a bunch of development time and then you have to migrate your entire database over to the new schema. With NoSQL, you can take any category or product type and add attributes and new categories at will without having to rework schema, so it’s super fast for developers and very flexible for merchandisers. So Nike, with it’s uber-large and dynamic catalog, can create new tags for thematic categories like Gender Neutral and Europe-Designed very easily. This agility is especially useful for temporary, seasonal categories you want to throw up for a specific campaign.
- I mentioned clickstream data as an unstructured data type, so being able to incorporate trending and popularity scores into merchandising is another bonus of taking catalog and merchandising off the SQL database and onto NoSQL.
- Another practical application of this is adding new channels and extending your business model. Here’s an example from REI of a missed opportunity, and what many large brands are forced to do when they’re limited by monolithic platforms and monolithic databases that are difficult to change. Here we see lots of products for travel, but also REI Adventure Trips - awesome, REI is getting into the travel industry
- The problem comes when you click into Adventures, you’re in a different experience that’s siloed from the main product catalog. So trips obviously have their own product data and attributes for filtered navigation and their own reviews, but it’s a shame that they’re not natively integrated with the gear catalog
- And even more unfortunate is members can’t add travel to cart or check out digitally. The only option today is to call. To create an account requires new credentials, because this experience is running on a different system entirely. And sadly, REI can’t cross-sell gear with these trips – a HUGE missed opportunity for personalization and basket building. Microservices would support a few things here. Catalogs running on NoSQL databases could handle new attributes for this new product type just fine, they could be added to the main catalog or integrate with the gear catalog and recommendation engines, customer accounts and most importantly, checkout, so customers can have a seamless digital experience. There wouldn’t be a need for two disparate platforms to run and maintain.
- Shifting gears to an example of microservices in action – Barnes and Noble’s Book Graph is a great example of using clickstream and graph data to create an interactive merchandising experience. Graph data involves connections between objects and often some kind of real time or trending component, or it could involve semantic elements like natural language processing
- So this mashup of catalog data and graph data lets you click on a book and discover – in their words -- unexpected connections between one book and the next.
- Who knew that a Stevie Nicks biography could be related to a John Grisham novel? The applications of this can get very deep when you start thinking in terms of Big Data and the ability to index book text and find associations within the content of the product (similar to how apps like Pandora recommend similar songs). Now you are far beyond even customers who bought this bought that, or “more like this genre.” You can potentially connect with social graph data as Facebook has an open API, as do other networks. So microservices, APIs and flexible NoSQL databases are the ingredients to make experiences like this possible.
- And I want to mention another benefit of moving off monolithic, relational databases. SQL databases must contain all their schema within a single database, and the more complex this relationship between tables and columns and rows gets, the slower your application can become, because data has to be stitched together with SQL joins between all these tables here, there and everywhere.
- And what’s more, enterprise commerce databases are very large, and can only scale vertically which means you need to migrate to bigger and more expensive servers as you add customer records and your catalog grows, and you need to store more and more data.
- If you max out your capacity and don’t ramp up fast enough – the ENTIRE database can go down, and that means your site breaks and all hell breaks loose in the IT department.
- The beauty of microservices is database independence, so you can have multiple servers and back up servers, and with NoSQL databases, you can even shard a single database across multiple servers, and this can benefit performance to boot.
- ALRIGHT, we’re almost at the finish line, everyone, thanks for keeping up with us… Let’s talk about running services in parallel, or more than one version of the same service. Why would you want to do this?
- Well, one classic example is B2B and B2C functionality. Most enterprise commerce platforms have B2B capabilities but were built B2C first, and B2B companies don’t all have the same, straightforward requirements so you likely have to customize the heck out of your monolith, or in some cases run two different platforms from different vendors which of course is not ideal. With microservices you can leverage the core parts that serve both sides of the business and run versions of areas with special requirements. Each instance can be owned by its own development team and run on its own deployment schedule, so there’s no competing priorities between business units and everyone can can get their wishlist items checked off in reasonable time. Order management is an example of this. Say B2B needs its own warehouse locations, wholesale, distributor and reseller rules, custom invoicing capabilities, split shipments for central purchasing departments, different shipping rules, rates and carriers for larger orders, credit terms management, different returns authorization processes and even B2B marketplace integrations.
- If you sell internationally, you may want to run two versions of your checkout microservice, one for your domestic and one for your internationalized site. Each can scale independently, so Black Friday’s not going to slow down your European checkouts, for example, but you can also take advantage for cleaner code. You can separate the database calls and the integrations with currency converters, tax codes, payment types, shipping and rate shopping services, et cetera. And you can also optimize your checkouts at the code level, not just the UI level.
- Microservices also let you do advanced A/B testing, not just for UI elements that you can swap in and out with basic conversion optimization tools like Google or Optimizely. Microservices let you test code-level changes and send a split of traffic to different instances. One example is a one-click checkout against a multi-step, but even further, emerging options like fingerprint recognition or voice enabled checkout, split test it before you make it default.
- OK, if any of these practical applications inspired you, or if you have your own ideas, how can Skava help you?
- If you are looking to migrate to a full, turnkey microservices platform as an alternative to replatforming to another monolith, we have a hosted and managed version that can take you to market very fast, and that’s Skava Commerce Cloud. If you want to take the strangler approach and connect microservices to your legacy platform or gradually migrate over, or even if you want to do a full migration but have very custom requirements, Skava Enterprise has you covered. And if you want to build your own microservices or integrate third party microservices, we have a comprehensive framework and API and orchestration layer that works with everything, and because it’s ready to use, you get to market way faster than building yourself.
- Skava’s proud to be ranked top of all platforms evaluated by Gartner for its 2018 Magic Quadrant for Digital Commerce platforms for modular, flexible implementations, and we’d love to explore how we can help your organization.
- Just fire us an email to sales@skava.com And now back to Hassina for some closing words and our Q&A period