Deploying SAP Hybris on the Apcera Platform
As companies have started to gain interest and allocate dollars to the initiative of getting their applications out of (or mostly) their on-prem and collocated data centers, many have run into some challenges with their existing traditional applications. Sure, you can lift and shift just about anything to the cloud nowadays, but how to do it in a way that aligns with current business objectives and that will be the most effective and efficient in terms of the application lifecycle and IT operations has left many IT organizations scrambling for answers.
Despite the challenges, there is a way to effectively move these traditional applications to the cloud with little effort, and even gain profound efficiency and agility along the way. To further illustrate this, let’s talk about SAP Hybris for a minute.
This is one of many traditional apps out there, but also one that is critical to the business and its bottom line. Let’s spend a few minutes going over how organizations can achieve value in the areas below when leveraging the Apcera Platform to run their Hybris environment:
- Financial savings via a reduction in infrastructure costs
- Agility and efficiency to DevOps throughout the application lifecycle
- Improved efficiency around Day 2 Operations
As we have talked with organizations about their initiatives around how they are planning to move Hybris out of their data center and into the cloud, most of their environments end up looking like the diagram below. They are typically a clustered environment, with multiple nodes, running on their own piece of infrastructure (i.e. VM, cloud instance), and the usual suspects of firewalls and/or load balancers in between.
That is a lot infrastructure that has simply shifted from an on-prem data center to a data center somewhere in the cloud. There is nothing wrong with this approach, but part of moving to the cloud is to help make your application environment more robust, right?
With Apcera, this same Hybris deployment reduced the required infrastructure footprint by more than 50%. Apcera allows the applications to be scaled dynamically to help ensure the right amount of resources are being used, and only when needed. There is no longer the need to over provision your cloud instances to ensure something like higher network bandwidth. Also, Apcera’s capabilities for abstracting away the networking and routing functions will allow you to remove any load balancers that may have been included as part of your Hybris architecture. In many cases, the web tier (i.e. Apache) can also be removed and replaced by the built in web server/router within the Apcera Platform.
Enhance DevOps Processes
Thinking about the time it takes to iterate through the build, deploy and testing process for an application like Hybris can be very time consuming— not to mention then having to deploy code and execute the test cycles. With Apcera, you can enhance your DevOps process and achieve a huge reduction in the time it takes to build, test and teardown your Hybris environments. Apcera’s use of packages will help create re-usable artifacts for the bulkier pieces of your application (i.e. base Hybris code and its application server). Now, when you need to build and deploy, these ready to use packages become part of your deployment. The hour(s) of time it used to take to provision a server and build out a Hybris instance can be reduced to about 10 minutes within Apcera.
Apcera’s use of parameters for configuring Hybris across multiple environments helps to reduce manual configuration steps. Apcera has capabilities that allow you dictate the configuration of Hybris across each iteration of the lifecycle. Rooted in the product is a policy engine that dictates everything the application and user can do, which will help prevent any kind of human error throughout the lifecycle. For example, if Java 9 is ok to use in dev but not in prod, Apcera has the flexibility to allow the user to make this choice in the appropriate environment, while the policy engine will enforce the proper guard rails if the wrong version is attempted to be deployed where it shouldn’t.
All of these capabilities come without a cloud provider lock-in. Apcera is able to manage your multiple cloud and on-prem infrastructures as a single fabric, which enables your dev teams to develop and build freely without the need to customize their configuration and process for various cloud infrastructures. If there is a need to shift an application from one infrastructure to another at any point in the lifecycle, the configuration, networking, etc. for the application will move right along with it. There is no need for additional preparation to the new infrastructure prior to making this type of change.
Day 2 Operations
Most of the organizations we meet with admit that most of their focus in these cloud migration initiatives in around Day 0 and Day 1. They need to help teams get an environment provisioned, access to that environment and help ensure it is stable to deploy their applications. Day 2 operations has historically been more of a reactive approach than it has proactive. With Apcera, you gain a built in proactive approach to your Day 2 operations. Every application’s log file is centrally located within the Apcera UI, so there is no longer a need to server hop to look these up. If you’re using a log analytics product, like Splunk or ELK, Apcera can push all of the log data out those products as well. If you use an APM product of some kind, those agents can be added to each workload (as a package) at build time.
Secondly, you will be able to n-scale your applications as needed. Whether it is for a known peak period or one that comes along unexpectedly, Apcera will be able to help scale up or down without any manual human configuration. If there are situations (i.e. failover) where the application needs to not only “fail over” but execute this to a completely different cloud infrastructure, Apcera can facilitate that as well. Managing all of your infrastructures as a single fabric will automatically add efficiency and agility to your current operations processes.
Real World Results
- Reduce HW footprint to support Hybris E-Commerce 6.1
- Example Customer: Reduce AWS footprint by more than 50%: 24 server to 7: Saving Money
- Example Customer: Approximately 14 F5 load balancers no longer needed: Millions in Savings
- Easy Application scale up and down
- Example Customer: Scale any tier of Hybris without configuration Changes!
- Fastest Hybris deployment model
- Example Customer: Deploy complete Hybris Stack in 10 minutes (dev, test prd)
- Example Customer: moved from 4 deploys per day to 8! Faster Innovation
- No Code customization required - no lock in.