Platforms and Microservices - Is There a Middle Ground for Engineers and Tech Strategists?

Executive Buy-In: Selling Your Digital Transformation Strategy

by Doug Platts

https://by.dialexa.com/platforms-and-microservices-is-there-a-middle-ground-for-engineers-and-tech-strategists



Dialexa

We are on a mission to make every

company a great technology company.

We work with organizations to define and

execute digital transformation strategies to

improve business operations and customer

experiences. Our services include:

• Multi-Year Technology Roadmap

• Platform Engineering

• User Experience Design

• Custom Software Development

• Hardware Prototyping /IoT

Your technology strategy is the key to executing successful digital transformation. But if you talk to engineers and strategists, there are opposing views on the best way to leverage technology.

Get the full write up of this slideshare HERE

https://by.dialexa.com/challenges-cios-face-as-companies-change-rapidly-and-what-to-do-about-them



https://by.dialexa.com/selling-your-executives-on-digital-transformation

https://by.dialexa.com/selling-your-executives-on-digital-transformation

While engineers might push for a pure microservices architecture, strategists may take a step back and consider the long-term implications of that decision on the enterprise. Is there a middle ground?




Our own VP of Engineering, Samer Fallouh, and Head of Technology Strategy, Russell Villemez, discussed this topic to see if there was some middle ground to drive innovation more effectively.


http://dialexa.com/about/samer-fallouh



http://dialexa.com/about/russell-villemez





To read more you can find the full article at https://by.dialexa.com/platforms-and-

microservices-is-there-a-middle-ground-for-engineers-and-tech-strategists




How Do You Define Platforms and Microservices?




Samer: Platforms are systems that can support multiple applications. They provide data, business logic, and communication protocols to end users, not just in a front-end / backend form, but also to multiple mobile apps, third party systems, other developers and platforms, etc.


https://by.dialexa.com/positioning-your-software-platform-strategy-for-success-a-technical-perspective



Microservices is a type of architecture used in building platforms by dividing it to the smallest units possible. These units are independent and each should do one thing and one thing only, but do it very well. This type of platforms can also support multiple applications.




Teams sometimes choose this architecture to address obvious future scalability needs, and to implement agile methodologies. Instead of one giant monolith, you have more manageable components that can support agile demands.




Now that’s from the engineering perspective, Microservices is more than just a type of a software architecture, it’s an agile culture as well. You’ll need to find harmony between ops and engineering to be successful in implementing Microservices.




Russell: Microservices have been pitched as highly modularized and decoupled—something a team can form around and have independently deployable services without worrying about dependencies with other services, data, or tech infrastructure. They are considered the solution to the problems associated with monolithic apps.




But this is not our industry’s first run at solving these problems. In the 60’s and 70’s, a monolithic business application was written in assembler or COBOL and our attempts to modularized these things came in the form of macros and procedure calls. But binaries were still large and monolithic.




Later came client/server computing, and with it RPCs which worked over the network. Smaller binaries became distributed - a huge shift away from the previous notion of “monolithic”.




Then web applications and SOA came along, which led to externalized methods for registering and finding services with published API’s. At the time, this was the epitome of “decoupled”. And now, microservices advocates refer to applications built for the SOA generation as “monolithic”. I guess it all depends on your perspective!




But here’s the thing that applications from every generation must deal with: how to best interoperate with the world around them. And that world is increasingly not homogenous.




So whether you are maintaining legacy code, or writing microservices code, you will eventually have to integrate with a wide variety of things that do not fit the latest container technology. And that’s where platforms come in. Platforms simplify the task of integrating a wide variety of applications and data across a diverse technology ecosystem.




Does your software platform strategy support your business demands?

Download or free eBook: Platform Thinking: Creating Real-World, Scalable Platforms

https://by.dialexa.com/platform-thinking-creating-real-world-scalable-platforms?hsCtaTracking=162583c0-836e-45d5-b1d0-bc5c5b1ff37a%7C5d2c8c22-1ea3-40ef-94c8-5d580cab6180

Is This an “Old Companies User Monoliths” vs. “New Companies Use Microservices” Debate?




Samer: Microservices is a modern software architecture and is highly used in building platforms nowadays. It’s not old vs new conversation, I think it’s more like what different types of platforms are there and how do you decide on which architecture your platform should use?




Russell: I agree. Old vs. new is too simplistic. The question should be “how big is the need for integration across different technologies?” Granted, established organizations can have a lot of complexity built up over time, while newer organizations have less legacy and are therefore more homogeneous. But old and new alike can benefit from microservices, and both old and new can benefit from a platform approach.


https://by.dialexa.com/the-business-advantage-of-custom-platform-engineering



At the scale of the enterprise, where the need for integration across a wide variety of technologies is the highest, enterprise integration platforms are absolutely critical for connecting systems of all types, including point solutions developed using microservices.




In fact, microservices cannot participate at the enterprise level without the implementation of an architectural pattern for enterprise integration.




A platform is the very thing that allows packaged software, SaaS applications, legacy apps, and everything else to talk to each other in a predictable manner. A microservices app is just another endpoint in that context.




Samer: The more common type of platforms you hear about today is the Application Platform, which is a software platform built to empower a growing business. These Application Platforms serve a specific business, i.e. a business that connects a type of providers to their consumers, or another that provides a set of services to customers through applications (mobile & web) and data to third parties.




Microservices approach is very common in Application Platforms. It made sense for these platforms because with processes like Continuous Integration and Continuous Delivery concepts are empowered in Microservices.




CI/CD processes bring so much value to the product you’re building; from better quality, to faster feedback loops, to confidence when releasing to production, and even more integrated team where everyone has visibility, respect, and empathy to what other departments are responsible for building and delivering!




Companies like Netflix and Amazon adapted Microservices to solve the problems they were facing in their monolithic systems, they were able to experiment with new technologies and have an innovative mindset in their culture.




How Do You Decide When to Use Microservices?




Russell: All things being equal, there is no reason not to adopt microservices technologies, especially when combined with agile development practices. The two go hand in glove so well. But things are not always equal. Some problem domains rarely change.




How often does the Finance function want to change how annual reports are produced for shareholders? (Hint: it’s an annual report). And the dependencies associated with that change would be hard to isolate to just financial analytics apps, much less a single microservice. So that would be something requiring plenty of planning, followed by a rare software change.




On the other hand, how often does Marketing want to change the messaging on a product web site? In some cases, it’s more than once during the time it’s taking you to read this article. The point is that we should be looking at the scale and pace of change in the problem domain, and choosing our architectural patterns accordingly.




We should be asking “what is the likely shelf life of this application?”, “How often will it change?”, “How uncertain are we of the business requirements?” and “How mature is the problem domain?”.




Samer: That’s a great way to put it. We spend so much time focusing on becoming more agile and innovative, but if you don’t take a step back to look at the big picture and the long term goals for your business.




One reason I can think of to use Microservices is when you know your system is going to handle different types of traffic for different types of services, for example you have a constant stream of data that you need to process while your billing service is just on demand.




This way you enable having different scaling metrics for different microservices. You’ll have teams focused on different pieces of your platform and you’ll trust them to implement it with little direction and guidelines. You do need a maestro team to orchestrate this effort.




Russell: It sounds as though the middle ground is very context-sensitive. In some cases, we should not worry about enterprise platforms, where speed and failure and discovery are paramount.




In other cases, it would be a very poor business decision to charge ahead with building a purist microservices architecture without an predetermined platform strategy.




Sometimes that platform might be limited to a specific application or problem domain, and other times that platform might need to be enterprise-wide. The most important thing to get right is knowing where along that continuum we should land, given the intended outcome.




Samer: Absolutely. Going with Microservices helps you move faster. You don’t have to understand every detail in the business logic before you start development, you can identify small chunks that need to be built and assign them to different teams to start making progress right away. But it can easily become a trap where you focused on everything except the big picture. This way, you’d end up stuck in an architecture that keeps you from moving the business forward.




Adopting a Platform Engineering Mentality in Your Organization




The value of microservices can’t be denied—especially as digital transformation weighs heavier on organizations of all sizes. However, swinging all the way in favor of microservices is just as dangerous if you lose sight of the larger technology architecture.




In other cases, it would be a very poor business decision to charge ahead with building a purist microservices architecture without an predetermined platform strategy. Sometimes that platform might be limited to a specific application or problem domain, and other times that platform might need to be enterprise-wide. The most important thing to get right is knowing where along that continuum we should land, given the intended outcome.




PROPERTY OF DIALEXA LLC ©2017 - CONFIDENTIAL & PROPRIETARY

Thank You

Doug Platts

VP of Marketing

[email protected]

If you are looking to undertake a digital transformation initiative, contact Dialexa today and see how we can help make your company a great technology company.

Get the full write up of this slideshare at https://

by.dialexa.com/platforms-and-microservices-is-there-a-

middle-ground-for-engineers-and-tech-strategists

mailto:[email protected]


