Recently, IDC Research Director Gary Chen and Perficient’s Victor Wolters, Enterprise Strategist, presented a webinar that discussed application modernization, containers, and the value of Red Hat OpenShift on AWS.
They say that regardless of where you are in your digital transformation, it’s never too late to think about application modernization. Whether you’re looking to modernize an existing application or create a new application to support your workloads, containers and OpenShift on AWS provide a myriad of solutions to your business challenges.
Watch the recording to hear Gary and Victor discuss:
- Enterprise Adoption of Containers
- Trends from IDC Research on Container Adoption
- OpenShift on AWS IDC Study
- Perficient Use Case Featuring Containers and Application Modernization
Webinar Transcript
I’m Rick Klein, I’m with Perficient and I’m an Alliance Director. I’m your moderator for today, and I’m very happy to have you in attendance for Building and Deploying Applications on OpenShift with AWS. This is a very interesting topic, and one that’s receiving a lot of industry attention: modernizing applications, containerizing them, and putting them on a platform like AWS, with OpenShift. It’s a very timely discussion as we go forward in modernizing applications and moving things to the cloud.
I’m Gary Chen. I’m a research director at IDC, and I cover software-defined compute, which includes virtualization, containers, and cloud infrastructure platforms. I’m here to talk to you about containers. We’re going to start off by going over enterprise adoption and trends from IDC research on container adoption. And then we’re going to talk specifically about a study that we did on OpenShift on AWS where we talked to a number of customers and built a model to quantify the benefits of using OpenShift on AWS.
Overall, this is enterprise container growth from a high level – this is a really good way to get a picture of what’s happening in the industry. This looks at all of the installed enterprise compute in the world today. You can see most of it is VMs, in the dark bluish color. And bare metal is in the red; obviously, this has been trending downward as things become more and more virtualized. The top area that you see in the light gray is containers.
Containers can run on bare metal or VMs. That view isn’t shown here, but this is the primary vessel for that application. We started off pretty small and today, we’re probably around 5% of total enterprise compute is containers. There’s still a quarter left in the year, and certainly COVID has gummed things up a bit. But I think we’ll probably get to around 5%. If you look at 2023, it’s going to be over 20%. That’s really, really good growth. But it’s going to be a long transition for most people.
When you look at the five-year compound growth rate, on average, container instances are doubling year after year. There’s massive excitement about this technology and a lot of use cases.
We’re looking at what the top drivers for enterprises are to deploy containers. We see a couple of different areas. One of these is modern workloads and modern apps, specifically AI and ML, which have risen recently. That’s due to the dynamic, scalable nature of these workloads. We also see that edge and IoT is starting to rise up. Containers are nice and lightweight, and infrastructure is distributed and automated, which fits in well with IoT.
Some of the other things that I think are more commonly known as benefits of containers is delivering software faster. That comes with higher developer productivity, where they can spend less time messing around with infrastructure and shipping code and more time actually coding. On the ops side, it’s about increasing operational efficiency and more automation and workflows and more apps going out the door.
The other part of it is around modernization and migration of existing applications. While it would be nice for all enterprises to be able to develop everything greenfield with modern technology, that’s really not the reality. They’re taking a lot of existing applications and starting to modernize them for their digital transformation. A lot of that is migrating to the cloud. While containers is a great technology, and it’s very standardized with the container images and Kubernetes, it can really help with migration. Containers aren’t a cure all for all kinds of cloud migration issues, but it’s a great tool and can really help.
At the top there, you see improve security. I think this is something a lot of people don’t guess right away. In our conversations with customers, we talk about how containers can also help with security in a variety of different ways. There’s a container registry, or catalog. All of your images are centralized, and it’s a great way to know what is being deployed and what the version of everything is. Letting you get a better assessment of what your assets are.
Two containers are generally used with VMs or containers or VMs. That’s another layer of isolation. If someone wanted to break out of a container and compromise a host, they would have to break out of the container and then break out of the VM. It’s dual layers of security and can be very effective.
The other part of it is how people start migrating to more modern infrastructures and modern methodologies. People report that moving to microservices is better for security. Because when you had a monolith, you really only had one security posture. You had this large thing that you had to defend against, and that was microservices, it breaks it up. Now you can concentrate on what the parts are that you really need to focus on, and are the areas where you can perhaps focus less. You can have more granular security postures versus a monolith.
With CI/CD, which isn’t necessarily a container technology, but is often hooked to container systems. This lets people update and patch faster. If they have to react to an incident, flaw, or update, they can do that much faster.
The other part with containers is this idea of immutable infrastructure. Out of the container registry, if you need to update something or roll out a new version, it’s killing off the old version to deploy the new one. Instead of going into an existing thing and changing the configuration, this solves a lot of the historical issues around configuration. This is the configuration drift. Containers can help a lot in those various aspects. Those are some of the most common ones that customers tell us they’re using to improve security.
What are the top container challenges that people are encountering? It’s interesting that security is the most common benefit, but also the top container challenge, and that’s because it’s a new technology. There’s a lack of experience, a lack of knowledge, and a lack of practices. People don’t know what they need to do. They know that it’s something new. They have to secure it, but they’re not really sure exactly the best way to go about it; the container systems can be very large. When you look at it from securing the entire pipeline from point, a container image is first created all the way to runtime. It’s a lot of area to cover, and that’s a challenge.
The second part has been data management. We see emergence with these new apps – AI and ML are very popular. These things are generating data. We see more and more stateful apps being run on containers. You have to protect and govern this data from a container point of view.
The next challenge is the universal plumbing across data centers and clouds. Most people have containers running in data centers, and they also have it running in public clouds. They need a unified control plane, unified management, and visibility into all of that without creating separate silos.
This slide looks at container instances – where do they live? On-prem is orange the gray is split between private cloud and more traditional bare metal or server virtualization. Blue is the public cloud. What we see here is that containers are really a hybrid technology. They started in the public cloud because it was linked to cloud-native development. As it became more and more mainstream, we saw it starting to grown on-prem. Now, it’s across all of those environments for a truly hybrid model with a particular affinity for public cloud. Public cloud has a larger percentage of containers than any other kind of infrastructure, like when you look at VMs. There’s definitely an affinity with cloud-native development and modern apps. Public cloud is a major factor when you look at container deployments today.
Now we’re looking at what workloads are being containerized. There’s a lot of excitement around these new microservices and cloud-native apps, but in the enterprise, the reality is that there are existing applications they have to deal with. We see a lot of containerization of existing apps. There’s a pretty even mix, very slightly tilted toward existing applications. But people are still getting a lot of benefit from containerizing. These legacy apps can lead to better utilization and higher density for a more modern workflow. It’s easier to distribute software packages and test them, even all the new applications. They’re not all necessarily cloud-native. There’s a lot of significant overhead today to implement microservices, and a lack of skills for people that know how to build them. That’s going to take a long time for people to transition into.
When you look at taking an existing application and containerize it, this is the process. There’s a range because you have simple apps and more complex apps.
When we asked customers to sort them into the level of effort and modifications that were required to containerize the application, about a quarter of them require significant modifications. Thirty-seven percent were moderation, and 40% were little to no model modifications. This translates into migration time because 27% of apps that are more complex apps usually take three months or more, with 12% of them exceeding six months for some of the more moderate and simple apps. People can do them in a week, so about 22% of them, they get done in less than a week. While the vast majority, about 45% or so, fall into that couple of months category. But it’s very workload dependent.
People also get better at it. You can switch for identifying what apps are, the containerized candidates, and what the processes are.
A lot of the containerization is around initially getting the app into the container. There are much longer projects around refactoring these applications. Right now, almost half of all applications are containerized. Often times, refactoring takes place over a long period of time – it could be years. This number has actually gone down since the early days of containers. Users are more realistic of what can be refactored and to what level. With new technologies, I think people are often very optimistic about it, and so they’ve definitely gotten more realistic.
A lot of the process is targeting what parts of the app you really want to modernize. With monolithic apps, people will keep a static monolithic core, which has a very slow rate of change. There’s not much development going on. They’ll carve off the faster changing parts that need to be met, A to B, where B is modernize, and there’s a lot of fast acting development going on. They will refactor those and you’ll end up with a Frankenstein app with some legacy parts and some more modern parts. This is often in conjunction with a migration to public cloud.
Now we’re getting into the IDC business value study, where we interviewed customers who are using OpenShift on AWS. We quantify the benefits that they achieved across a variety of different areas, from developers all the way to infrastructure. The full paper will be made available after the event – it has much more information and a deep dive into the numbers.
In terms of average and the average annual benefits for organizations, it’s almost $11 million. We saw these go into four basic buckets. The largest area is business productivity benefits. This is higher revenue from more functional software and faster apps, and services being rolled out, as well as higher employee productivity for people using those.
The second part is IT staff productivity. This is around more efficient operations and management from the Kubernetes platform and from public cloud. It’s more automated software-defined and API-driven. It makes their lives much easier. Then the third are of benefit is around medium risk mitigation. Less downtime and more user productivity by having more resilient infrastructure and more scalable infrastructure. So the app is available regardless of load.
The last area, which looks very small here, is nothing to sneeze at. It’s really around IT infrastructure cost reductions and the cost of the actual platform itself.
Looking a little deeper into some of these metrics, we looked at the effect on application development and the time required to deploy new compute and storage. There is a reduction in absolute time, as well as a reduction in staff time required. This is done in the cloud. With containers, it’s in a modern, API-driven way, often with infrastructure as a code. Whole automated processes take less IT staff time and involvement to service those requests. Developers get the resources that they want faster so they can get to work coding. This looks at both kinds of provisioning – the underlying cloud infrastructure, which will be storage and VMs, as well as the user-facing side of getting a container or getting customers to them.
We saw almost 24% higher developer productivity with OpenShift on AWS. Developers are able to focus more on code and letting the infrastructure be less of an obstacle. They have faster development lifecycles due to the containers and Kubernetes and the modern tools in a modern workflow.
The other part is that they’re able to access AWS services from the OpenShift environment. As a developer, you can access a lot of the services that can help you develop applications faster, like a managed database. You can also get access to GPUs or AI as a service and blockchain as a service. You get a lot of that component tree that can help you build an app faster than if you had to create all of these elements yourself.
This slide looks at the reduction in app costs. When we look at the cost of the platform, which is the hardware and the software, we found that was reduced and the savings was then able to be reinvested into developer staff. Overall, they’re able to shift 10% of the overall budget away from the platform into developer staff. This increases the software velocity even more. You have more people that you’re able to hire and provide them with a more productive environment, which accelerates software development.
This looks at the five-year IT infrastructure costs, and we found that it was 54% lower cost on average across the cost of the infrastructure and platform itself. The IT staff time required to manage it and the cost of downtime and product and lost user productivity that comes from that.
In summary, we found there’s a five-year ROI of 661%, five months to payback. Some of the other interesting metrics that we found were that people were able to double the number of new applications per year that they’re able to roll out. The business is able to innovate, get into new markets, and expand into new geographies.
Ultimately, that turns into higher business revenue for the organization. We found that was almost $44 million higher revenue on average per organization by moving to OpenShift on AWS.
Just a few minutes on Perficient. Obviously, we’re working directly with IDC with AWS and Red Hat to bring you this information. Perficient is actually a publicly traded company – we had about $570 million revenue last year and hope to get over $600 million this year. We have 25 locations around the globe – 22 of those are in North America. We were founded in 1997, became public in 1998. We have a little over 4,500 employees. We’re in most of the major cities that you might reside in, with people in China, India, Columbia, and London.
We’re a global delivery company. Most of our locations are in North America, but we look at things a little differently. We want to make sure that we’re offering you the right skills at the right places, but also at the right cost. So we have a global delivery organization – we have people who are offshore, near shore, and onshore. We manage all of our client engagements here in North America but have locations across the globe.
We have a longstanding relationship with Red Hat, and we’ve been working with AWS for quite a while as well. We have over 15 years combined experience with the two partners. We have quite a few deployments in place already, with over 100 OpenShift and AWS deployments. We have a lot of experience doing this, and can make it work for you and your applications. We were the 2018 Rising Star Partner of the Year for Red Hat just before they were acquired. We have solution expertise across different cloud platforms, multi-cloud services, app modernization, migration, microservices, and containers.
Containers really are becoming the de facto standard for deploying and running applications across all the different computing models that exist. It’s important to note that this is part of making a more agile enterprise and a more adaptable one. Given what’s going on in the world today, both agility and adaptation are very important elements to business success.
At this point in time, I’d like to introduce Victor Wolters, our Principal Enterprise Strategist.
Thank you very much, Rick. Thank you, also, Gary, for sharing that information – it will fit in very well with what we’re talking about here today. We wanted to share with you one case study from a client that we’re doing container work at. You’ll see as I go through some lessons learned and background on the actual engagement that a lot of real-world facts have come out of this case study that support what Gary shared.
This particular company that we’re working with is in the shipping logistics industry. They’re global in nature and have facilities all across the globe.
They came to us with some very specific questions and concerns, primarily centered around one large monolithic legacy application that has been around for many years. It has a lot of applications that are mission critical and stay around for a long time. It had reached a point where they were having some challenges, and along with that, their business was expanding and growing at a rapid pace. They were finding it harder and harder to keep up with the demand and meet what the business unit was asking for in terms of making changes and modifications. The challenges for them were centered around a variety of different areas in regards to this legacy application.
One of the biggest challenges was the cost of maintaining this particular application. The technical debt associated with this one application was fairly large, and it was getting hard to justify continuing to spend money on it.
Another important challenges was a lack of ability to roll out new changes and provide improvements to the application to keep up with the business demand. They could barely get an upgrade out a year, and when upgrades rolled out, they needed to make more upgrades. This is a common issue we see with these applications that have been around for a bit.
So they came to Perficient because we’ve worked with them on other projects. They presented us with their challenge and what they thought they needed to do. We came up with a solution that filled their top requirements. The most important one was the ability to make changes and deploy those changes on this application in a timely manner.
They were, at best, trying to get to a year, given the current architecture, design, and everything else that already existed. From a business perspective, they just couldn’t live with it any longer. As mentioned before, reducing costs was a big issue.
As we talked about it more and discussed what they needed to do, we realized they needed automation. They had done pockets of automation in different areas and different parts of their IT team across the globe, but they hadn’t centralized or honed in on particular tools or standards for how to automate, how much automation, or where they were going to do it. The team that supported this particular application was doing everything manually, which added to the cost and slow down. There was a need to ramp up the automation quite a bit, combined with the notion that it was taking a long time to get things done, get changes made, and get them rolled out. This ties in directly to what Gary said on his slide about top drivers – they needed to modernize the application, increase developer productivity, or increase the number of new releases in order to get new features and functions out to their clients who were demanding it. These were common things that we see from clients when we’re talking about existing applications and modernizing existing applications.
We began to talk about exactly how they wanted to accomplish this and how they want to accomplish it. And that led us to moving into recommendations.
In the recommendations that came down, one of the recommendations that we made right away was a movement to cloud infrastructure. This organization has a mindset where they had been avoiding cloud and not utilizing cloud in a significant manner. It’s a usual way of moving into cloud for large organizations that do a little bit here, a little bit there. We made a recommendation that they needed to modernize the application and that they should do it on a container platform. There was a wide variety of reasons we felt they should do that, and why they should move to a container platform. Fortunately, they were already thinking about containers, but they were thinking of a different container platform than Red Hat OpenShift.
We support both platforms, so we knew the pros and cons of both. We had a conversation with them, and they ultimately settled on Red Hat OpenShift. There were a few things that stood out on this platform that made a difference – one was automation and the ability to implement automation from the very beginning of the process to much deeper into the overall deployment process. The Red Hat platform was going to be a much better support and match to some of their other technologies, and in terms of what their teams were aware of.
It’s not uncommon that one part of the organization is unaware of what another part of the organization is already doing. We moved into conversations around this container platform, and we looked at some of the other groups we’ve worked with and pointed out that they had already implemented Red Hat OpenShift and had two clusters up and running that could be leveraged for this engagement. We moved forward with our modernization, and were going to first do a replatforming. This is in line with Gary’s slide where he talked about it not just being for new apps but for existing apps.
We started with refactoring and would then move it to the container platform. It was a tough decision because it’s such a large application. There were some concerns and questions about the ability to replatform without having to do significant rework of the code to make it work. We did some pilots and test checks to validate a few pieces of code. Through these pilots, we were able to determine that we would replatform and then refactor the application to be a more modern structure with APIs and microservices and things of that nature. As you can see, a lot of the decisions came down to different recommendations from where we were, but none of them were big game changers.
We started to analyze – we have a delivery process when we’re doing agile development and delivery work where we iterate through and double-check and make sure that we’re making progress. But we’re also looking at lessons learned from the last sprints we’ve done. As we examine that for this particular client, the lessons broke themselves into two natural categories of business lessons learned and technology lessons learned.
A lot of these lessons are specific to containers versus some of them that are broader than that. You’ll begin to understand a bit of what it is if you’re not in the container world or if you’re working in a container, some things to look for.
Some of the business lessons we learned were very important: count the cost, check the benefit. Obviously, they had already been counting the cost of the current legacy app and they knew what it was costing them to maintain that and continue to deliver. It might be a big caution to them in terms of lost business and not being able to deliver this additional capacity. But one of the problems – one of the things I really hadn’t given a lot of thought to – is that the approach we’re taking with a container platform is starting to bear fruit on is the notion of delivery timelines. How long it takes to get something out the door and deployed in production, in a safe and consistent manner, and fully tested, validated, and in compliance with all regulations. They really started seeing the benefit of that within the first sprint, as we began to move forward and began to replatform the code into the container platform and really began to see the benefit of what containers can bring to the table.
There’s a good opportunity to start reducing costs. Gary showed that you get 10% back on your development time by moving to this type of platform, and that’s in essence where we started seeing that 10% start to happen. We’re not spending a lot of time going back and forth with the business. When rethinking requirements or things of that nature, it was a very quick turnaround and the benefit is that we’ve gotten a tighter connection to the business. The business folks and the IT folks are talking frequently, and they’re having meaningful conversations, especially when it comes down to acceptance testing and those final phases of testing that made a big difference there.
It became very apparent that as you evaluate those processes, in terms of collaboration with the business folks, they start to go through and analyze their business and identify new features on a broader basis. When business units are making decisions about new services or products they want to bring to the table.
One of the things that was happening was these businesses are often working independently, and there wasn’t a full inclusion of IT and finance and everyone else, and the early stages of looking at things. This process started bringing more upfront engagement and involvement, and they started sharing right away new ideas about what they need to do. Collaboration really started to come into play and started to make a huge difference in how they were beginning to move forward. The attitude about IT began to change. They also began to realize that IT really could help them, and better define their future and where they’re going to go in with this one application. It really made a difference in terms of being able to define that for how they began to create these new services and new apps going forward.
Along the same lines, there were stakeholders that hadn’t been consulted about some of these activities. We began to talk to those other groups and began to interact with other groups, and we began to get a new set of inputs and began to feel a lot more support. As this is an organization that has a typical IT group broken up by function, some groups were in different countries and time zones. There’s all sorts of challenges around those areas, but as we begin to include more people in the daily stand ups as well as in other design workshops and things of that nature. The collaborative effort began to gel, which ultimately paid big dividends at the end as we moved into refactoring and moved to a more modern structure within the application code itself.
And finally, we began to start working with the business folks to verify what they were seeing from our customers and hearing from the customers in terms of what they wanted to do and what they needed out of this application because parts of this application were customer-facing, but most of it was internal. A lot of people hadn’t thought the external customer had a big voice in this. The more we talked about it, the more they began to realize they do have a voice in this. That leads us to the technologies lessons.
One thing that became very clear is think before you leap. The point of this lesson was that they had a couple of different groups within the application development group itself, as well as some supporting groups, infrastructure groups, and others like testing and QA. They all had dissenting opinions about which tools you should use and how you should do the process. You should walk through things of that nature to actually get this application replatformed and modernized. There was a tendency to say that since that group said we should use that tool, then we should use that tool.
There was no real consideration about what the impacts of using that tool. What would happen? What are the ripple effects? Any of us who have been in the technology and information world for any length of time recognize that there’s no single platform or tool that’s going to solve all problems. You always have this multiplicity of things you’re working with, but you need to think about it before you make that decision and thinking about it. That doesn’t mean you shouldn’t try new tools, but you need to come to the conclusion about whether they’re valuable in your particular portfolio and what you’re working with. You should limit it to things that you clearly see some benefit that’s going to come about before you jump into it.
The second thing here is really thinking about how you go about doing this replatforming and modernization. Is the use of container technology really as much as a technology platform?
As much as it has anything else, that brings together all of these different components and a whole new way of putting together applications and deploying, testing, and maintaining applications. It calls for a whole new way of thinking about these applications and beginning to think about these applications as platforms, as solutions, not just as applications. What I mean by that is that the code you’re going to deploy on this container and the pods, and all the configuration within your service mesh, and all the different parts of this platform, are going to allow you to put that together with some other components around it. It’s really forming a business solution platform that could actually be leveraged to delivery multiple applications, as we’ve thought of applications in time past. As you’re beginning to make this move to the container, and you begin to modernize an application to move it to a container platform, you’re creating a new one.
Be sure you’re thinking about the architecture that codes the APIs and microservices as a business solution platform that could actually service a variety of different needs within the company. Think about creating a business solution platform that fits underneath a digital business platform where you’re delivering the actual services and products to your customers. If you think about it, this fits into the whole main stream of what we’ve seen in trends over the past years. We moved from centralized mainframe computing to many computers to microcomputers, and nanocomputing and then moving to the cloud. There’s a mega shift in trends. It’s along the same lines as this shift of how we do code and how we create new business solutions. The container platform is a significant part that helps you find that path and a way to move forward, and then to continue to leverage what you develop over and over again.
The third point is solutions. You really need to think about what you’re doing in terms of moving things over and how, when you’re moving to a modernization phase, if it’s an existing app and you’re modernizing it. Be sure and think about how you could modernize it, break it apart, separate it, and put it into APIs and microservices in a way that those APIs and microservices can be reused in a different way. The container platform allows you – a platform like OpenShift – tremendous flexibility to be able to do that with the use of your containers and segue many things within the platform.
Then, it’s about the access to data and the ability to quickly build out MVPs to test out a new service and product offering. If you do the coding right, in terms of modernizing or even new code, you will find a lot of reusable components that will make a big difference. The container platform allows you to put it back together with automation in a way that you couldn’t today with the applications you have available.
Finally, think loose, fully integrated processes. We know there’s not a standard we should seek to live up to. But we’ve seen hard code connections, where we had hardcoded IDs and passwords for one piece of the solution to talk to another piece of the solution. We want to get away from that kind of stuff and use the container platform and the power of service mesh as a way to begin to integrate processes that may run across multiple solutions and applications that you deliver. Be sure that you’re tying together your automation correctly, and that your automation scripts and your pipelines are designed and built in such a way that can easily be modified to bring in additional capabilities and deliver additional capabilities for your business. It will really pay off as you move forward.
One of the challenges that we run into with almost every client that we work with, is the ability to automate this full process – the governance process – from end to end.
We’re taking it to the next level. When we’re moving collateral to a container platform, it’s a great opportunity to start thinking about patterns. When you think about patterns, you’re thinking about them in terms of your architecture and your network. You’re thinking about patterns of flow – communication flow, traffic routing – and what you’re doing to actually modernize an app or move it forward. Again, the container platform allows you to establish a pattern in terms of how you do that. You can actually leverage that pattern through your CI/CD pipelines to go to the next application or next solution and deploy quickly. You’ll recognize it right away – that’s a pattern. You’re speeding up the process and getting a jump ahead and making something happen. As you think about patterns, think about automation – that’s one of the reasons for patterns. When those patterns are automated, you’re able to easily grab them and bring them over.
Automation is one of the big selling points for going to a container platform. Don’t forget: it’s portability, the ability to deploy it in the public cloud, on-prem, private cloud, or a hybrid option. There’s flexibility with the container platform. The container deploy supports your solution. And deploying your solution into that requires that you have a certain level of automation to make it go as smoothly as possible to be able to redeploy the application quickly, simply, and easily and spread it out across multiple different applications. Then, you’ll know a bit about the old and the new – there are some things we’ve always done that we need to continue to do, but do you need to do them the way you’ve always done them? Is there an opportunity to think about it in a different way?
The container platform can bring that to the table for you, and we’ve seen that with this client. We’ve been able to automate tremendous amounts of compliancy, testing, and risk mitigation. They didn’t have it automated before and it was taking a lot of time to get deployments into production. Because those things weren’t automated, we were able to automate quite a bit of that and still meet the same requirements that were there before.
For us, the application modernization that Perficient follow is very similar to this. The only thing I wish to point out is that there’s a patter there. There is a methodology that we follow for these modernization journeys. You won’t always have exactly these steps, but you’ll go through this, and it’s an iterative, repeatable process. You’re going to cycle through multiple times to actually get to the modernized application and get it ready for deployment.
But you need to think about a few key concepts that I’ve mentioned previously. You need to think about collaboration – what you do and who you collaborate with. Is there a variety? You need to think about your research tools and how you do that. How do you want to modernize? Do you need a greenfield to do your research? When you get into the construction phase, don’t be afraid if you need to change the process. If it’s greenfield and you’re trying to develop an MVP, don’t be afraid to fail and fail quickly. Deploy, test, fail – use the repeat process here to continue to modernize and get your application moving forward.
Questions
- What industries or industry segments have been getting the best traction from migrating to containerization in the cloud and comparing that to other models in similar industry segments?
Containers are going to be a pretty horizontal technology. The market for virtualization is for anyone who wants to develop faster apps and software development. Right now, the two leading industries are IT computer and the software industries. If you’re in the business of making software or providing some kind of Internet service, like a Google. But we’ve really seen financial services be the lead. There are needs for new technologies like AI simulation as well as user-facing banking apps. Then manufacturing, healthcare, retail, and telecom for network functions, 5G, edge, and IoT. Those are the most common ones.
- Are you seeing an acceleration in modernization projects? If so, what types are you seeing? How does the customer decide what applications to modernize?
We’re definitely seeing an acceleration in modernization. It’s a big initiative and a lot of companies amid the current economic and global environment have accelerated with the pandemic. One example is the working from home scenario; the other one is transacting business differently. In retail, they’ve had to shift to curbside pickup quickly and many businesses have moved transactions online. It’s at an unprecedented scale and demand.
At Perficient, we’ve seen an acceleration of requests for application modernization, and we have a group almost exclusively focused on that and we have a methodology for approaching it. You saw the overall high-level process for deciding which applications to modernize, and it can be tricky in many cases. It’s difficult to apply it across a wide range of industries and application types, but I would say that what we’re seeing a lot of clients lean toward is to modernize some of their more difficult and larger applications, only because there’s so much business logic and mission criticality to the company that’s worth it to them to start to modernize and try to get that application to a better state that allows for faster response and adaptation. It’s an application that represents a pretty significant revenue flow within a company. I think the other kinds of applications we’re seeing with modernization fall to the other end of the spectrum. They’re wanting to get into the container platform – they want to understand it, the infrastructure, and the people, so they take a low-risk application and begin to move forward. It’s two opposite ends of the spectrum that we’re seeing people select the applications for.
Thank you. We’re at the top of the hour.
