The evolution of Adobe Commerce to reduce your TCO

Transcript

Welcome to this session, to the evolution of Adobe Commerce to reduce your total cost of ownership. I’m Sandra Gonzalez, Product Manager at Adobe Commerce. I have a wide experience on product management, and I now own the total cost of ownership domain for Adobe Commerce. I’m working on different projects and initiatives to help you reduce the cost of upgrading and the cost of maintaining our product. You are probably familiar already with the upgrade compatibility tool. We also have a bunch of other initiatives to actually help you with the process. Just for you to know a little bit more about me, so I love to spend time with my family and friends, and doing this in the nature is like the perfect spot. Hopefully, we will have some open areas to go for after this session, and you can enjoy the rest of your days as well. Today, I’m with Smita, and we’re going to talk on how to reduce this cost of upgrading and all the initiatives that we’ve been working on. I’m going to leave you, Smita, to introduce yourself. Hi, everyone. Thank you so much for attending this session. My name is Smita Verma. I’m a Senior Product Manager and responsible for both platform security and platform health. I have six years of experience in application and data security, and three plus years experience in product management. Additionally, I also have six years of development experience in security, legal, and backing. I’m looking forward to your participation in this session, and thank you again for joining the session. I’ll pass it over to Sandra to introduce the agenda, and then we’ll take you through it. Yeah. Thank you. Just as a reminder, we’re happy to answer the questions at the end of the session. You can use the Q&A area that is on the top right corner on the chat. Feel free to ask your questions there, and we’ll be taking care of those at the end of the session. The main reason for having this session is to share all the initiatives and changes that we’ve been introducing on the release strategy, what we’ve changed, why we’ve changed it, and which tools and other initiatives you can benefit from to make the upgrades easier. That’s what we’re mainly going to talk about in the next 25, 30 minutes. Just to highlight the importance of what we’ve been working on, and what we will be talking about today. We all know that upgrades are a critical part of Adobe Commerce, and they are actually required for you to stay secure and perform. Definitely security is one of the high priorities for upgrading. 83% of security incidents happen on outdated versions. IBM estimates that a security breach in average can cost up to 3.86 millions. That’s definitely a lot of money. Then together with this, we have performance that can have an outsize and cumulative impact on a business. Every second of latency has been shown to reduce conversion rate by 7%. Page speed is a leading CEO ranking factor. All these are the main reasons why upgrading. Taking advantage of each and every release is in the best interest of your business. However, as we know upgrades can be a challenge, they can be complex, also time consuming. That’s why we will walk you through the latest changes on our release strategy, and which tools and initiatives you can use to minimize the cost of upgrades. The goal, our goal. Let’s start making very clear what we’re trying to achieve with this. With all the changes that we’ve been doing and all the initiatives that we’re working on, what we will achieve is to reduce the total cost of ownership of your projects. We will do so that upgrades will be easier, faster, and cheaper. The way we will be doing this is by minimizing the frequency and the complexity of upgrades. We will do this while at the same time, we will accelerate the release of innovative features through independent feature releases. Having said this, now I’m going to let you, Smita, walk us through all these changes that we’ve been working on. Perfect. Thank you so much, Sandra. I’m here to walk you through the new release strategy. I just want to emphasize what Sandra just mentioned. We want to reduce the total cost of ownership by making it easier to upgrade, as well as by release at the same time, we want to release new innovative functionality through independent services. A complexion in this goal will take place in three different changes, which I’m going to talk about right now. In all the following slides, I’ll go and do a deep dive of each of these changes, but here is a high-level overview. First of all, as I said earlier, that we are going to release new functionality as independent services outside of the course commerce application. This will help us to achieve a thinner core by making releases less often, at the same time, making core really stable by reducing the number of new features in the core application, but being delivered as independent releases. Secondly, we are simplifying our release schedule. In 2022, we are reducing the number of releases that we’ll make into the core commerce application from four to three releases. Lastly, we are updating our lifecycle policy to align commerce application end of support dates with PHP end of life dates. This will help us to have less frequent and more stable releases because we will be minimizing the breaking changes, which are backward incompatible changes, at the same time, maximizing the time between the releases that cause breaking changes. Let’s talk about thinning the core. How are we going to slim down the core? One of the things that I mentioned was releasing features as independent services. Going forward, we are going to have less frequent releases. At the same time, we’ll have more stable core, which will help our customers to stay up to date at a lower cost. At the same time, we are also releasing innovative new functionality through our independent services, making it possible for us to deliver fast and new scalable features with no effort. And then let’s talk about next the quality patch tool. Well, these are quality patches from the community contribution. So earlier with our current process, the quality patches were made available by the community members, but we had to wait until the next release in order to utilize these quality patches. But now with the quality patch tool, these patches would be available to the customers, which will be provided by the community members. It will be verified by the maintainers, and then it will be made available through the quality patch tool. So again, these will be individual fixes for quality issues, and it will be available for customers to search and apply as soon as they are available. So the customers now can get access to these fixes at a very quick time without having to wait for the next patch release. Next, let’s talk about the simplified release schedule. So as I said earlier, we are committed to simplifying our release schedule as well as making it more predictable. We are reducing the frequency of commerce patch releases from four to three in 2022. And these releases will happen through three main release vehicles. So first is patch release, which will include security, performance, and high priority quality fixes. Think of 244, for example. Next is feature release, which is new feature will be released separate from the core. And here you take an example of payment, which is offered as an extension. Thirdly, security patch release will be patch release containing only security update. For example, 245P1. Here’s a snapshot of our 2022 release calendar. As you can see, what I discussed in the last slide are three release vehicles. They are highlighted here as well. Talking about the feature release, so we will have feature release throughout the next year. You can see there are six feature releases and here we’ll be making updates to the new functionality that are being offered through independent services. You can see that there are three patch releases as well. 244 and 245, which is happening in March and August. And again, I want to remind you that this will contain security, performance, and high quality, high severity quality issues. Now, if you look at the last release for the year, which would be in October 2022, this is also a last opportunity to release feature independent releases as well, along with security only patch, because we want to keep the security release as well. Security only patch, because we want to keep the holiday calendar in mind and make everything light for our customers, but at the same time provide support for security issues as well as compliance. So we will be releasing 245P1, which is based on the Q3 full patch release in the end of the year. And in the last, let’s talk about the lifecycle policy. But before we get into that, it’s important to understand that Adobe Commerce, it’s built on PHP. It’s a popular third party scripting language. Now with PHP, a new version of PHP is released every November, every year, and it is supported for the three years. Now, what this means is that Adobe also has to keep adding support for the new PHP version and updates its code base. Unfortunately, moving to a new version of PHP typically involves more significant updates, which is also called the backward compatible changes. Now we want to reduce the number of backward compatible changes in our releases. So for that reason, we want to align us end of support dates with the PHP end of life date, so that we can reduce the number of releases which contain backward compatible changes, at the same time maximize the time between the releases that cause these breaking changes. So let’s talk about the updated lifecycle policy. So as I said, we are shifting the release, end of the commerce release end of quality support dates to align with PHP end of life dates, so that now we have less frequent releases which cause breaking changes. At the same time, our release schedule are aligned with end of life PHP dates. And clarifying that the only way to get security updates is by upgrading. So if you want to stay secure, the customers have to upgrade to either a full patch or a security only patch. So here is a snapshot of our upcoming end of quality support period. So as you can see, these are for the versions that we currently support and the versions that we will be releasing next year. So let’s start with versions 240 to 243, which are based on PHP 7.4. So the end of support end of quality support for these versions will be based on end of life of PHP 7.4, which is in November 2022. So what that means is that 240 to 243 would be supported until PHP end of life date of PHP 7.4, which is November 2022. And then let’s talk about the releases that we are making next year, which is 244 and 245. Now these versions are based on PHP 8.1. And the end of life date of PHP 8.1 is November 2024. So these versions would be supported until the end of life date of PHP 8.1, which is November of 2024. Now, what I’ve discussed in the last slides was all about our quality support period. I also want to emphasize on our security support period. So in case of security, the customer must upgrade either to a full patch or a security only patch to remain secure. Unlike quality fixes, the security updates are not backported to an earlier supported version. And the customer must take the latest patch or security only patch to stay secure. Now let’s try to understand this with the help of an example. So let’s take an example for a customer who adopts our release 244 in March 2022. Now, when the next release happens in August 2022, the customer takes the security only patch 244 P1. Now in Q4, when we release our next security only patch, the customer skips that particular security only patch. Now, what that means is the customer no longer has the latest security updates. And now, since the customer is on 244 P1, even though it’s a supported version, the customer cannot get the security updates that were made in 245 P1 backported to 244 P1. So they have to upgrade in order to be secure and in order to make sure that all the security issues in their environments are being addressed. So I know that was a lot of information, but I want to quickly recap all the three changes that we have made to the release strategy. So first of all, we now have a thinner, more stable core code. Which will help our merchants to make upgrades really quick, easier. And then secondly, we have simplified our release schedule. So now it’s from four releases, we have shifted to three releases. And then lastly, we have updated our lifecycle policy to align with end of life of PHP dates. As a result of that, we are maximizing the time between the releases that cause these breaking changes. So with that, now I’m going to shift over to Sandra, who will be talking about minimizing the cost of upgrades. Thank you, Smita. So yeah, now that we’ve talked about how to minimize, how we’re minimizing the frequency and the complexity of our core releases. So I’m going to talk about other initiatives and tools that we’re working on to support our customers to help you minimize the cost of upgrades. So first, I’m going to talk about the upgrade compatibility tool. I’m sure that most of you are well familiar with it. But in case of you haven’t had time or you haven’t used it yet, the upgrade compatibility tool will help you, the goal of it is to help you and your team to understand the scope and impact of an upgrade very early in the process. So we’re going to talk about the upgrade compatibility tool. And the way this tool is doing this is by comparing and analyzing a customized version on your project, on your instance, with the target version that you are trying to upgrade to. It is a clear tool. It has very easy to use commands and it’s executed in a matter of minutes. So basically, when you run the tool, in a few minutes, UCT identifies all those places where conflicts might potentially occur when you are planning to upgrade. So what it gives you is a detailed checklist for you to actually complete the upgrade. And it makes this very fast and makes upgrades faster and cheaper. The tool will give you a list of all those issues that you will have to take care of. We have three different levels of severity, which will help you understand the complexity and criticality of the issues that you have in your project that you should be working on and fixing for the upgrade. And it will also give you a very short and easy to understand summary with the total number of issues identified for those areas that we are validating. And it will also give you a complexity score for you to understand how complex the upgrade will be. This last month, we also released a new Magento PHP Storm version that is introducing the upgrade compatibility tool. The goal of introducing the tool within the PHP Storm plugin is to help you to proactively prevent issues even earlier in the process while you are developing customizations. With this, what you will get is make sure that the code that you and your team is producing will follow our best practices and quality guidance to prevent all those issues that you will have to work before breaking, if not. So if we move forward, I want to share the Slack channel. So we have this Slack channel for you to be able to join us. And you can ask their questions, share feedback or ideas with our team and also with the community. And also, we have here the Dev Talks wiki page. Smita, if you can move forward, please. Very quickly. So please join us. And one more. Thank you. Yeah, this is the Slack channel. So please join us and be able to free to ask any questions there. Then the next initiative that I want to talk about is Marketplace extensions. So we know extensions are critical to an e-commerce store and they are also a key part of the Adobe ecosystem. However, we know that they can make an upgrade more difficult if they are not compliant with our latest release, if they are not compatible with the latest releases that we have. So that is why we recently updated the Marketplace compatibility policy to ensure that all Marketplace extensions are compatible with the latest release version within 30 days. What this means is that all extensions today will have to be compatible with 243 version by November 30. As this is the first time that we introduced this policy, we’re giving more time. But looking at the future, this will be our new normal. So with every patch release, extension owners will have 30 days to upgrade their extensions to be compatible with the latest release one. Otherwise, their extensions will be delisted. The mean delisted means that they won’t be accessible through our search or category pages. And if you reach to that extension directly with the product page link, you will be able to download it or access it only if you already have the granted permissions. But people will not be able to buy that extension if it’s delisted. So having up-to-date extension, which is our target, will significantly simplify the upgrade process. We know that normally, projects have a lot of extensions on their instances. And if they are not compatible with the latest version, it’s very difficult for you to upgrade to the target version. With this, we expect all extensions to help you with the upgrade process. Then, as also Smitha mentioned, let’s talk about the quality patches tool. So the quality patches tool has been used already for some time. But now, we are using it to deliver quality fixes. So until now, we incorporated quality fixes to the core, which resulted in a slow and very time-consuming exercise. So you had to wait for the core to release to be able to get a quality fix. And a lot of fixes did not make it to our release because of the limited resources we have, the high number of issues, and the priority of the issues. Wait, you had to either reach out to support or to fix the issue by yourself. At the end, all these require time, resources, and, in summary, money. So starting this year, we introduced the quality patches tool to speed up the process to deliver quality fixes. So we have changed, as you most probably are aware of, and if you saw Stanislav’s session today, or if not, you can watch the recording. So we introduced the quality patches tool to deliver these quality fixes. And we changed the community contribution model to empower the community to deliver quality fixes through this tool. So the quality patches tool will help us to deliver individual patches, either developed by our team, Adobe, or by the Magento open source community. It allows you to apply, revert, and view general information about all individual patches that are available for the installed version of the Adobe Ecommerce or Magento open source project that you have. So you can apply patches to both Adobe Ecommerce and Magento open source independently of who developed the patch. So thanks to these changes, it is now much easier to get quality fixes. So you do not have to wait for a new release, and you do not have to reach out to support. It is then much more efficient to maintain the core of your project. And not only easier, but it’s also faster. While making the process much easier, you will be able to fix issues quicker, and this will immediately translate into better results. So you do not have to invest your team’s time to find the solution for an issue if it’s available as a quality patch through the quality patches tool. Then last but not least, what I want to share with you. So as Smith already mentioned, and as we have shared already on our release schedule, next year March we are releasing 244 with PHP upgrades. So in order to minimize the impact of these changes, another initiative that we have implemented is the release of four monthly beta releases that are starting October 18th. So with this, you will be able, if you subscribe to the program and you have all the information on this GitHub, Magento beta program wiki page, you will be able to get very early code for what we are expecting to release in 244. You will be able also to share feedback to help us address all those issues that will be potentially identified. So again, we invite you to join the beta program. And to finish, I would just want to leave you with one very quick idea that with all these changes, we expect our future upgrades to be like superheroes. So they will be easier, faster, and cheaper. And that’s basically it. So I don’t know, Smita, if we have any open question on the Q&A that we can address. Let me see. How much of this microservices will be local sources? So I think just trying to reply to Dan. So how much of these SaaS microservices will be local, altered, hookable, open source as some of our current extensions are? So our current approach is to deliver new features as independent features. One option is to deliver them as extensions and others as a SaaS services. So that’s our plan. In the meantime, when we get to more features delivered as independent ones, we will have to maintain the core. That’s why we’re improving all this process just to make the core maintainability much easier. Let’s see what other questions. Okay. I think we have questions but answers as well. Thanks, Chris. Yeah. Chris, just add to that comment that some SaaS capabilities might be offered to open source customers. Through the services code itself. Thank you, Chris. I think all the other questions have been answered. Am I missing something? Yeah, I don’t think so, Sandra. I think all the questions are answered. Okay. So I think we’re done. Thank you very much for attending and for joining us today. Feel free to reach out. So if you have any questions, we’ll be more than happy to help you. Thank you, everyone. Bye. Have a good day. Thank you.