Recent studies from Gartner highlight the increasing adoption of Internal Developer Platforms (IDPs) in software engineering organizations. By 2026, approximately 80% of these organizations will have a dedicated platform team, with around 75% delivering IDPs to their engineers by 2025. Gartner's Hype Cycle for Software Engineering further emphasized this trend.
In light of these developments, it becomes crucial for IT professionals to carefully consider the decision of either building or acquiring a platform for their company. Efficiency is a key driver in today's fast-paced environment, making the role of a platform even more significant.
At Mercado Libre, the largest marketplace and fintech company in Latin America, we have been at the forefront of platform engineering for over eight years with the development of our platform FURY. Our journey has provided us with invaluable insights and lessons learned we are eager to share. Whether you are in the early stages of platform implementation, actively building your own, or contemplating the acquisition of a platform, our experiences can provide valuable guidance and support.
Our journey
Established in the late 1990s, Mercado Libre initially operated as a Java-based monolithic system. However, as our company expanded and reached a scale of 100 developers, we needed help maintaining this model. Source code conflicts, high coupling, and chaotic deployments resulting in frequent downtime became prevalent issues.
In the mid-2000s, we transitioned towards a microservices architecture. This approach aimed to empower developers with greater autonomy, reduce coupling, and enhance agility. The process involved gradually breaking down the monolithic structure into smaller units, eventually achieving true microservices organized by business units. Within this context, developers enjoyed considerable freedom.
At first, productivity grew allowing rapid feature growth, and our time to market became much better. However, productivity started to drop as the complexity of the requirements and microservices plus the lack of standardization caused teams to spend more time operating infra and resolving incidents. In addition, the microservices' complexity raised concerns regarding governance, cost efficiency, and security. The reliance on individual developers' decisions introduced a high cognitive load, and the need for governance created potential pitfalls. This realization prompted us to seek a solution to catalog services, establish centralized and controlled development and deployment mechanisms, standardize technology stacks, and enforce security policies and cost controls.
Image: The graph shows the exponential growth in the number of developers versus the technology. The big cube represents the monolith, the little cubes the microservices, and the bear represents the FURY Internal Developer Platform. As we can see, FURY played a huge role in supporting this growth.
Eight years ago, our Internal Developer Platform (IDP) FURY emerged as the answer to these challenges. In this article we’ll share some key lessons learned from building and driving adoption for the platform.
Buy or build only when the time is right
When we started building FURY, we didn't ask the questions we know to ask today. IDPs hadn’t yet gained widespread recognition, and the term platform engineering was not commonly used.
If we embarked on the platform journey today, we would ask whether to build an IDP from scratch, acquire a comprehensive off-the-shelf solution, or combine many existing products.
The answer to that question will depend on the context of the company. If Mercado Libre were to start the IDP journey today, we might not have developed something from scratch. Instead, we would look for platforms or components on the market to meet our needs.
But there’s a more important question you should ask before “buy or build”: is it the right time to invest in an IDP?
Many companies lack a well-defined and established product. Despite this, they tend to get deeply involved in critical technical issues when they should invest in a good Minimum Viable Product (MVP) instead.
It's important not to be seduced by technology! As technology enthusiasts, we have a natural tendency to do so. Above all, investing your potential in your product is necessary. After all, your product is what keeps your company alive. When we started investing in building our platform, we already had a very well-established business and clear problems to solve.
The construction of our platform did not compete with the construction of our product. On the contrary, it supported the evolution of our product.
You should also consider the size of your development teams. The technology teams are generally small at the beginning, so the entropy and complexity are lower. Your company might not need an IDP in these situations.
Seek wins relevant to your stakeholders
At first, we focused on developing services and features to enhance the user experience, eliminate repetitive tasks, and standardize actions. For example, self-service environments enabled developers to spin on a development environment in a few minutes and removed a lot of cognitive load. Quick wins like this were crucial in getting the buy-in from top leadership necessary to sustain the platform.
Platform teams should measure their IDP’s impact on productivity and efficiency, and use those numbers to drive adoption. For example: how much time did a developer spend to have a production environment before and after? How many security vulnerabilities were not included? Try to connect the impact you see to larger business objectives.
It is important to understand that it's not always about creating something grand from the start. Automating small tasks and demonstrating the benefits to the organization can be just as effective. By following this approach, we can show tangible results in an agile and efficient manner, increasing support and involvement from key stakeholders in the company and contributing to the continued investment in the platform.
Avoid imposition
As we added more beneficial features and services to FURY, platform adoption increased gradually. We did not impose the platform on users because we believed the benefits offered would lead developers to use it voluntarily.
Platform teams must build something their developers will choose to use when building their applications. Adopting this mission can help define the platform’s roadmap and how to improve the user experience.
We incentivized developers to start managing their microservices on our platform by showing them possible productivity gains or cognitive load reductions. For example, we would show a developer how much time they could save managing infrastructure using our platform. We would also extrapolate the benefits to a time interval in the future. Understanding the benefits helped motivate developers to use our platform.
When developers notice the platform's benefits in their daily lives and see themselves as an important part of the adoption movement, platform migration happens naturally. We achieved this by sharing successful FURY migration use cases with developers. These developers then became true advocates of the platform.
Driving platform adoption will take some time from your platform team. I advise that platform teams choose some emblematic cases in which a business requirement migrated to your platform. Collect data such as lead time and time spent with configurations and compare them before and after the platform. As always, extrapolate in time.
Platform teams must also measure developers' engagement instead of relying solely on observation or the number of users. Establishing communities based on discussion forums and surveys can help collect feedback and gauge real user acceptance.
Implement controlled freedom
Having complete freedom versus controlled freedom is an eternal trade-off that platform engineering must deal with. An IDP significantly abstracts developers’ work, which can naturally limit their choice of programming languages, technologies, or services. Finding the appropriate level of limitation is a challenge intrinsically linked to the nature of the company, the composition of its teams, and the expected changes associated with IDP implementation.
The presence of a robust technology team dedicated to Operations (Ops) and how skilled developers are with DevOps can help answer the freedom dilemma.
At Mercado Libre, we have something very close to the concept of NoOps. NoOps is an approach where developers primarily focus on business development and problem-solving instead of worrying about operational tasks related to infrastructure and server scalability. In our company, developers are relieved of the direct responsibility of managing the infrastructure, allowing them to focus on business needs and creating innovative solutions.
Mercado Libre’s developers are responsible for the operation and uptime of their apps. Still, the platform abstracts the DevOps work by provisioning and managing the entire microservices and cloud services infrastructure. However, it is important to highlight that even with this approach, developers still need to master fundamental concepts, such as the principles of the 12 Factors, to ensure the creation of high-quality and efficient applications.
This type of controlled freedom, wherein the developer does not need to touch many aspects of Mercado Libre’s infrastructure, helps ensure excellent security, compliance, and efficiency. It provides an environment where developers can work productively and get support from the platform’s guidelines and policies.
A platform will never meet all needs
Recognizing that your platform cannot handle every possible scenario is essential. Developers are creative and will have needs the platform cannot fulfill. Integration with legacy software is an excellent example of something difficult to handle with a platform but essential. It is crucial to plan what will be outside the scope of the platform.
Platform teams must establish processes or tools to monitor and manage what the platform does not provide. In this context, various business problems are likely to arise, considering that, naturally, there will be a lower level of governance in these areas. It’s essential to understand the different scenarios within this universe and provide resources and guidance for the evolution of your platform.
At Mercado Libre, approximately 20% of our infrastructure is created outside FURY because the platform does not support the technology or provide a similar service. We refer to this as the "Off-FURY" world. We have developed Infrastructure as Code (IaC) based tools to handle this reality, maintain excellent compliance, and understand user activities, preventing leaks, deviations, or vulnerabilities. From the developers' point of view, the possibility of having infrastructure outside the platform is important when necessary, as it does not limit innovation.
Additionally, we monitor various metrics to make more informed decisions regarding the platform's evolution. For example, if some services are used off-platform more frequently, we’ll implement them in the platform more urgently.
Support and training are essential
Providing support, training, and good documentation to platform users is crucial. For example, suppose a developer encounters a problem with the platform and has to use an alternative solution to find a workaround. That developer is less likely to use the platform in the future. However, if the platform team provides efficient and practical support, the developer is less likely to turn to alternative solutions in the first place.
At Mercado Libre, we have a dedicated Knowledge Management and Subject Matter Experts (SMEs) area in addition to general support. The Knowledge Management team creates boot camps for developers to learn how to use FURY. We also have specific acceleration tracks and conduct various knowledge exchange events. The SMEs support developers on various issues, from using platform resources to more complex matters such as defining a solid architecture for a solution, choosing the best service for a specific problem, or performance tuning, among others. Just as important as generating this content is promoting it! At Mercado Livre, strong DevRel communities are in charge of promoting platform resources to users.
Don't forget about culture
Your organization’s culture is key to platform engineering success. When we first started building FURY, we underestimated its importance. Once we spent more time cultivating a culture of collaboration, transparency, trust, and thirst for knowledge, the impact of our platform grew significantly. New platform teams should understand how their organization’s culture might affect the outcome of their platform engineering efforts and communicate with stakeholders accordingly.
Next steps
At eight years old, the FURY platform is already very mature. Our next steps involve improving the user experience and making developers’ day-to-day work more productive. We’ll continue to add more features, resources, and services to the platform, expanding our ability to abstract cloud services and specific solutions. We’re investing heavily in improving uptime and better supporting market advancements in machine learning and artificial intelligence.
The platform's future is decided based on business needs and developer requests. Developers create and vote on features we should propose, ensuring the platform is never truly finished.
Conclusion
Mercado Libre’s decision to build a platform was undoubtedly the right one. FURY has provided scalable efficiency, allowing our developers to focus on creating the best products. We can’t imagine achieving the same level of growth without this platform.
Dealing with over 24,000 microservices, their interactions, and security issues, addressing each individually would be a monumental challenge regarding scalability and governance. The decrease in cognitive load and the gain in efficiency in various aspects such as costs, security, and productivity have undoubtedly made every investment in a platform worthwhile.
No matter how advanced the technology is, we need a solid and well-aligned culture to fully realize its potential. Culture is the foundation that supports all our achievements, providing the necessary context for the effectiveness and innovation of the platform.
If you want more details about our platform and journey, please don't hesitate to contact us. We’re eager to share our knowledge and learn from the experiences of other professionals and companies. Together, we can drive the evolution of IDPs and reach new levels of excellence.
Let's build a better future driven by innovation and the power of platform engineering!
.avif)
