Technical onboarding - SaaS offerings

Learn about the Adobe Commerce Cloud SaaS offerings, support, and other communications and some next steps.

Who is this video for?

  • Website managers
  • Commerce architects
  • Owners of e-commerce website

Video content

Transcript
This is Russell with Adobe, and this is your Adobe Commerce hardware handoff. We’re going to be covering SaaS offerings, support and responsibility, and what might be next after you’ve gotten to this point in your journey.
Adobe Commerce has several products that we offer as a service, and the intent is to offload some of the original tools that were built into the application and get them outside, and it does provide several benefits. Mainly, it takes the processing power that is used to, let’s say for example, search. All of that processing power that used to happen inside your application, if it’s on an external service, it’s no longer using up your resources, and processing can be manipulated faster because those tools are dedicated for that one feature. So, offloading some of these key known heavy tools, offloading those to a service is a great way to improve performance, and one of those will fall under search. So, as the Adobe Commerce comes shipped with Open Search, somewhere after 2.4.4, Open Search is now just installed at your standard search, but we do offer Live Search, and this is a great enhancement because it uses the Adobe Sensei, and it also helps with the machine learning algorithms, and it will give you a bigger, broader, powerful tool when you use it alongside with product recommendations. So, for search, just realize that Open Search will come with the application out of the box, but for Adobe Commerce Cloud, you do have the option of using Live Search, and there is no additional charge, and so learning more about that, which you can do in Experience League, is a good idea to have a great understanding of its power and its flexibility.
So, another option that you would have for a cloud service is product recommendations, and this also uses Adobe Sensei. This will be used in conjunction with Live Search, and it will, benefits would be that when you get to your checkout, or other areas that you’re trying to either cross-sell or up-sell or enhance the search results. Another service that we recommend is the Catalog as a Service, and the biggest benefit for this is the amount of processing power needed to look up product data, such as product details, category pages. All of that can be moved to the Catalog as a Service, which has been optimized for GraphQL requests, and has proven to be up to 10 times faster in retrieving that same data as if it was inside the application itself. So, Catalog as a Service is a great way to improve your overall site performance. The Price Indexer is another service that we offer, and this takes that very, very complicated task of figuring out what is the price to show to the customer, and all of that resourcing that is used to figure out price calculations is done on an external server, and so that means that all you need to do is just request the price and let that external service do all the work, and it will simply return the appropriate price. It’s a great way, once again, to take that in-process CPU and processing time and just let another service do it for you, and all you need is just the number. So, it’s a great option that you should consider as an external service. And the last one is App Builder. App Builder is a way to allow you to create your own functionality. So, as the previous ones that I just mentioned are pre-built and optimized for your use right away, App Builder is the area that you can build your own apps, and this would be a way for you to extend the commerce application without having to do in-process PHP code development. You can use this tool to build your app and then integrate it with any third-party solution that would fulfill that requirement.
The point is that all of that processing power happens on a different set of servers, and you’re going to use optimized and highly scalable APIs to retrieve that information. For support and responsibilities, we’re going to start with the shared responsibility model. And the overall premise behind this is that Adobe Commerce has its set of responsibilities, and the customer has its own. The Adobe Commerce is fundamentally a platform as a service, and it does rely on the shared responsibility model in order to make sure that you have the right tools in order to make sure that we handle our piece as efficiently and as professionally as possible. And then the customer needs to make sure that it takes care of the application patching and the code development. The different responsibilities does have a hierarchical structure, and we’re going to go at and describe that to a fairly good degree here, but you’ll also have the ability to read this in Experience League as well as some further documentation. As far as who’s responsible for what, Adobe is going to be responsible for the actual core application. So we’ll take care of that. We’ll take care of the core bugs that are pointed out. And then we’ll also provide security patching. The Adobe Commerce does leverage some partners, and they’ll take care of the actual servers and the operating systems, databases and all those things, as well as the infrastructure of the network. We’ll take care of making sure that any of the issues with latency or whatever are addressed. For anything that has to do with those topics, you would just create a support ticket, and then we will do our investigation and either do the patching or whatever is required to take care of the issue. You, the customer, you’re going to be responsible for adjusting and modifying the application to suit your business requirements. You’ll also have to do any API integrations. You’ll have to actually apply any patches. So whereas Adobe Commerce and the Adobe Commerce team might provide a patch, it is up to you and your tech lead or your architect to actually evaluate those patches, do your own QA on your site to see if they actually do solve your issue. And then once those patches are applied, get those deployed all the way up through production. And don’t forget to do any testing and QA. You’re also required and expected to manage your own customer data, your own product data, any special configurations that are unique to you, for example, payment processors or any code deployments. Those would definitely fall under your responsibility. But we do offer best practices and lots of documentation and experience to help give you a level of confidence and some direction to make sure you’re following best practices. As far as the shared responsibility model, it is Adobe Commerce’s responsibility to make sure that the application is secure, it’s flexible, and we will do all of the security patching and provide security patching to its services. So, for example, Elasticsearch, MySQL will take care of those. If you do find a problem, you can create a support ticket. And once again, we will take care of that piece of it. The customer’s security responsibility. Anytime you modify anything to do with checkout, you do need to have your own PCI compliance. The Adobe Commerce is PCI compliant out of the box. But once you do any modifications to areas such as checkout, it is up to the customer to make sure that you are still in PCI compliance. Cloud service provider security responsibilities. We do leverage most of the well-established cloud services. A few of them would be AWS or Azure, and there’s a few more. And it is those vendors’ responsibility to take care of their security, which means they’re responsible for making sure that the physical servers are safe and the security to those data centers are protected. That falls outside of Adobe Commerce. And then lastly on this page, Fastly, we do use them for our CDN, for caching of outdated service, you know, add to the content, as well as providing the WAF. And it is that company, Fastly’s responsibility to make sure that the WAF specifically is up to date and has, you know, the appropriate rules applied. You can read more about the shared responsibility model in the Experience League and the subsequent attached documentation. As far as creating a support ticket, you can log in and you would find your link in the top right-hand corner of your project and click on the Support tab. This process does get, it’s fairly easy once you get used to the UI. But remember, you could do a few things ahead of time to make sure that your support request is handled as efficiently as possible. First, you know, make sure that status.adobe.com is showing no issues because if there is something there, then you’re just going to be part of a wider, broader issue that we already know about. So there’s no reason to create a support ticket. But if you’re not and you’re seeing something that’s isolated to just you, that’s, you’ve already done one due diligence. When you do create a ticket, it is best to provide as much information as you can. And the reason for this is we have to do a triage process, which means we have to start at a fairly high level and then work our way down to make sure that, you know, some of these earlier checkpoints aren’t actually the culprit. So if you can create a support ticket and you’ve already done your research into New Relic to make sure that, you know, you can’t spot anything there, or if you do, include that in your support ticket. You know, make sure that you provide any, you know, screenshots or any logs that might be, you know, relevant to this issue. If you provide those early, then the support team doesn’t have to either ask for them or wait for them, and they can actually use them to do their initial triage. And that way your solution will come faster. So if you can, try to include as much detail as you can when you create your initial support ticket and also do as much self triage so that way you can hopefully catch anything yourself and you may not even have to create a support ticket. One of the things that we will find is that you may be creating a support ticket, but your versions of your Fastly or Elasticsearch or Redis are going to be out of date, or maybe even your application itself is out of date and is past the end of life. Just make sure that, as a best practice, to make sure that all of your composer packages and all of those, you know, code level things are as up to date, especially your commerce application, keeping that up to date and inside the, or at least outside of the end of life, is going to be important to rule those out as possible suspects. And once again, any third party software, anything that you do that modifies the core application, anything that’s external, we cannot support. As far as the initial support request, we do require a support consent. And the purpose for this is that we are looking at your infrastructure and we have potentially the ability to look at data inside of your database, which means we need your consent. So, in order to do this, you do have to log in to your site and you do have to go to the account settings and the privacy settings and then provide consent. And once again, this is a fairly flexible option. You can do it for a week, a month, or a year, or even indefinitely. What this does is this, if you do set it for an appropriate amount of time, we don’t have to ask you for this and we will, we do need to verify this every time you create a support ticket. You do want to make sure that this consent is only as long as needed. So, you do have to do this for every single request unless you do it indefinitely. But once again, do it for the maximum amount of time necessary to be successful. Indefinitely is an option, but once again, it’s probably better to do it at a shorter, you know, a shorter duration. You can also, once you’ve provided consent, you can withdraw at any time. So, if you did do it for a month and your support has been resolved within a week, just go ahead and withdraw that. Just do remember that if you forget this step, this will delay your troubleshooting because we can’t really begin triaging your issue until this has been done. There is more information about this that can be found on Experience League. As far as priority levels, we deal with the P1, 2, 3, and 4 levels. So, tickets are going to be auto-assigned and they can be escalated depending on the situation and what you’re going on with your project. For us, a P1 is a catastrophic incident. So, something that is affecting checkout, maybe your site is just entirely down. So, that’s what we would consider a P1. A P2 is your site does function, but it’s definitely, you can tell it’s at a reduced capacity. So, even though your customers might be able to check out, you know, it’s taking four seconds, five seconds, ten seconds to load each individual page, something like that. A P3 would be something that’s affecting your site, but overall, your customers can utilize it. Maybe it’s only affecting search results or something unique like some images. Not all your images are missing, but some of them are missing, things like that. So, that would probably be considered a P3. And then P4 is just when you have a general question like, you know, how do I get access to, you know, create a Fastly purge or something like that. So, you can create a support ticket for things like that. That would be considered a P4. And that’s where we will do our best efforts to accommodate those. But once again, those would just be general questions. They really aren’t supposed to be affecting your site performance. So, just once again, this is just for your knowledge that these levels exist and the reasoning behind them. So, the last thing that we’ll talk about for this is that the P1 category, this is only after your site has launched. And the reasoning is that if you haven’t gone live, then there’s really no catastrophic impact to your site yet. If you have any more questions, make sure that you visit Help Center. And there’s going to be links down below to help you get to these should you need them. As far as your continuing learning and certifications, you know, Adobe Commerce does provide some certifications that are either on demand or instructor-led, as well as some courses via the ADLS. Now, these are great to make sure that your team stays up to date and qualified, you know, and certified to do the best job. So, these are for your use. Some of them are free and some of them do have a fee attached. So, make sure that you go to the certification site and then ADLS to look at courses that might be applicable for your team. These will teach you, you know, how to do different things, some best practices, that will help you understand how to get your best performance out of your website. It also helps with training because, you know, the Adobe Commerce application does evolve. So, keeping them up to date is a very important task to make sure that you have a good team supporting your application. New Relic is an external tool that we use and they offer their own courses via the New Relic University. They cover everything from basic tasks all the way to in-depth training. So, once again, make sure you go to New Relic and look at their courses at New Relic University to make sure that you’re up to date on that tool and how to use it properly. You can also check out some of the resources that we have. We have community forums, we have a community engineering Slack channel, we have the very broad and vast experience league, as well as the developer docs and user guides. So, all of these are linked below. Make sure you continue to look at them and use them and continue your journey and your education on those topics. As far as some action points, once you’ve gotten to this point in your phase for this project, you know, once again, the first thing that we’ll probably have you do is configure Fastly because without that, you really can’t use the cloud project. Make sure that you understand and utilize and do performance testing. Please do this, you know, frequently and often. This will help detect issues as you’re building your application and it’s getting more advanced and more mature. So, performance testing is a great way to make sure that you’re not reducing capacity with new features that are involved. Definitely learn and understand our SWOT tool. This is going to give you insights into your health site and basically a score of your project. So, the SWOT tool, the Site-Wide Analysis tool, is a great way to make sure that you are still healthy and doing things appropriately and don’t have any known issues. As far as monitoring, make sure that you have proper monitoring in place. The Adobe Commerce application does have some core monitoring that is put in place by the support team. You are able to add and create your own monitoring. So, if you think that an APTEX score is, you know, let’s just say it’s, the threshold is different than what the core team wants, you’re allowed to create your own alerts to let you know that things are trending poorly and you can do your own proactive triaging. So, once again, knowing that you have the ability to create your own monitoring, you could set different thresholds for like CPU usage or hard drive capacity. All that is available through New Relic. So, definitely look at those and take some time to learn about the Observation Dashboard. This is a New Relic dashboard that has a set of tools that cover the entire application from end to end, covering everything from PHP to Redis to MySQL, hard drive capacity, you know, throughput. So, it’s a great tool, it’s a great dashboard, it’s available, and if you need, there’ll be links to the experiencing documentation, as well as other tutorials. Remember to review the security policies and the shared responsibility models. We went through support. Try to remember for best practices for support tickets, try to do as much self-triage as you can, provide as much background and information when you create the support ticket. That will help expedite the overall process. And finally, on the support ticket, make sure that you do provide consent because that will inevitably slow down the triage process because we have to wait for consent before we continue. And finally, on some action points, you know, make sure that your team and you are continuing your education and learning. Get certifications. That is a great way to prove that your team is taking the learnings and applying them properly and has a great understanding for how to use the Adobe Commerce product. And once again, those are all linked below. And that’s all we have for today. I appreciate your time. Please don’t forget to continue your learning and your education and experience league, and have a great day.

Acronyms

Acronym Dictionary
  • SAM solution account manager
  • CTA customer technical advisor
  • PaaS platform as a service
  • IaaS infrastructure as a service
  • CPU central processing unit
  • UI user interface
  • CLI command-line interface
  • SFTP secure file transfer protocol
  • CDN content delivery network
  • Fastly IO Fastly image optimizer
  • VCL varnish configuration language
  • WAF web application firewall
  • PCI payment card industry
  • TLS transport layer service
  • ACL access control list
  • IP internet protocol
  • HTTP(S) hypertext transfer protocol
  • SSL secure socket layer
  • DNS domain name service
  • DKIM domain key identified mail
  • SPF sender policy framework
  • API application programming interface
  • URL uniform resource locator
  • AI artificial intelligence
  • B2B business to business
  • B2C business to consumer
  • PWA progressive web application
  • PHP PHP: hypertext preprocessor
  • QPT quality patch tool
  • SCD static content deploy
  • SWAT site-wide analysis tool
  • APM application performance monitoring

Experience League documentation mentioned in the video

recommendation-more-help
3a5f7e19-f383-4af8-8983-d01154c1402f