If you work on a commercial product, in nine cases out of ten you use a development platform. It is easier, it is faster and the result is guaranteed. Obviously, before using the platform you have to have it deployed. Of course, you can do it yourself but in this case you will have to answer some questions first:
- Which operating system do I need for it?
- Will I need additional storage? How much?
- Do I need a database? Which one?
- Will everything fit on one machine or do I need more? Will I need machines of different configurations?
- How do I integrate the components to work perfectly? Will they conflict?
These are just a few basic things you have to think about before you start configuring your platform. However, there is an easier way - use a platform service in EPAM Cloud. The flow is ridiculously simple - you send one command and go out for lunch. When you come back, your platform is there waiting for you. You will have as many virtual machines as required, they will be optimally configured with all necessary components installed and integrated. Just like that.
Of course, it looks simple only when the difficult part is done. In fact, there is a lot of work behind each platform service and a lot of people who found answers to all those questions. In my research on this matter, I spoke with Stanislav Polchanikov of Cloud DevOps, the guy who actually "breathes life" into platform services.
In 2016, EPAM Cloud delivered seven new platform services. I thought putting a platform into Cloud is a lot of work. How did you manage that many within just one year?
This is because we changed the flow. Remember, we talked about how Hybris as a Service came to be (we did, you can read about Hybris development here - GS)? Well, that was kind of a pilot project, but it turned out so well that Pavel Veller, CTO of Digital Engagement Practice, said that the solution was too good to be used for just one project. So, we have applied it for six more services, and plan to continue.
Can you summarize briefly what is so special about the new development flow?
Before, EPAM Cloud Team used to write platform services from scratch. We wrote Chef recipes, experimented with different machine configuration to find the most suitable and put together Maestro Stacks starting the infrastructure. We researched for the best integration solutions and the most optimal components. No wonder the process could be rather lengthy and labor-intensive.
What we did with Hybris was somewhat different. It started with EPAM-FLEX working together with the Hybris Competency Center on the Chef recipes to automate Hybris deployment. At that time, they were not thinking Cloud yet, but Pavel Veller saw its potential and suggested making a Cloud service out of it. This is when we stepped in to develop a proper Cloud infrastructure - we found which machines suited Hybris purposes best and wrote Maestro Stacks starting them. We even came up with two configurations - Single and Large where you are getting as many as five machines, all automated.
So, the main point is cooperation with other projects?
Not just other projects - they actually use the platforms we are putting to Cloud. They are experts in the platform requirements and specifics, and can work out the infrastructure which will serve just right. This is priceless, as they look at the platform from the user's point of view and can see some minor details which we might overlook. For example, this year we worked together with EPM-AEM on enhancements to AEM as a Service. They are actually working on AEM and they know exactly what it has to look like. AEM is the first ever platform service implemented in Cloud, but this year EPM-AEM helped us to upgrade it - now it supports the newest product version and is available in two modes. We plan to continue working with the guys from EPM-AEM next year - integration with Jenkins is in the making.
Are you using the same technology you used with Hybris?
We even went one step further - we now engage project experts in writing Maestro Stacks for infrastructure creation. We at Cloud DevOps put it all together and integrate with Cloud.
Do you help them at some stage?
Actually, now it's not that hard. There is the Dynamic Discovering Framework which makes service development easier and more efficient.
Dynamic Discovering... Can I google it?
I'm afraid you can't. This is something we have invented. In a nutshell, it allows creating new services by discovering the already existing components developed by experts for other services. This way, you do not have to write everything from scratch. Oh, and there is one more thing - you can create Chef cookbooks supported both by Chef Solo and Chef Server without any special adaptation. Chef Solo is very popular with auto-configuration developers, so they should appreciate this solution.
Are there any services developed within this framework?
Yes, the most significant one is the CI/CD environment on which we worked together with EPM-ENGP. The Engineering Excellence Team is working on improving delivery quality and they needed a solution for automated deployment of CI/CD environments. As they were thinking on the company-wide scale, putting it to Cloud was a matter of course.
In 2016, together with EPM-ENGP we rolled out two Cloud services - Gerrit, for code review, and Sonar, for code quality inspection. They are integrated with Jenkins and thus form a solid CI/CD package. Here EPN-ENGP consulted us heavily on the specifics of Gerrit and Sonar and on their dynamic integration with Jenkins, while we contributed the automation part. At one point, they suggested replacing MySQL database with PostgreSQL for better performance, which we did in one of the recent releases.
And, to lift a curtain over the plans for 2017, an entire Project Framework is in the making. That will be a sort of a "CI builder" allowing to create a CI/CD environment best suited to the project needs, for example, by replacing Jenkins with TeamCity or Gerrit with GitLab.
There is also another project which used Dynamic Discovering for developing a platform service - EPM-DATM who worked with us on creating ATG as a Service. Now the service consists of an ATG server started in the Cloud with a whole range of Oracle products forming a complete e-commerce development solution. Additionally, a separate Jenkins server has to be started and configured to work together with the ATG platform components.
The development continues, and in one of the future releases ATG will come equipped with a Jenkins server started and configured automatically, thus creating a fully functional development environment
What about other platform services you have developed?
Oh, each had its own challenges. Let's take, for example, Sitecore which we did together with EPM-ACCL. The trickiest part was that Sitecore, being a Microsoft product, required a Windows server, while Chef auto-configuration performs best with Linux-based systems. Moreover, the auto-configuration scripts for Sitecore were written for PowerShell DSC, a native Windows tool.
But the solution was found nevertheless. The EPAM Cloud team took the PowerShell scripts written by the EPM-ACCL developers and added special "wrapping" for it to be processed by the Chef server.
And we continue our cooperation with EPM-FLEX
No, Hybris is now in the hands of EPMD-DSPK. And they have truly ambitious plans for it - to improve Hybris Large for increased performance, to develop an intermediate configuration between Hybris Single and Hybris Large involving three virtual machines and to implement a Hybris-Jenkins integration solution.
With EPM-FLEX we worked on a different platform - Magento. As e-commerce experts, they developed recipes for auto-configuring Magento as a Service. And soon Magento joined the family of EPAM Cloud services.
That is, indeed, a lot of work you have done in 2016. What are you planning for 2017?
As I said, some of the existing services will be enhanced an integrated to form comprehensive Cloud solutions. And, of course we welcome suggestions from other projects on development of new services. Share your expertise, propose new cloud services - and 2017 will be as productive as 2016. Or, maybe, even more so.