devopsy.kinsta.cloud

Tag: hybrid

Blueprints for a Secure, Future-Proof Hybrid Cloud

For today’s organizations, hybrid environments are a given. Whether for legacy reasons, regulatory requirements, or other specific needs, some of an enterprise’s critical data is likely to reside on, or in some cases, revert to, on-premises. However, other equally crucial data might be more efficiently and cost-effectively suited for storing and accessing in the cloud. Hence, hybrid.

Despite their logic and many benefits, hybrid environments bring new levels of complexity. And they bring greater vulnerability, with ever more devious cyber threats probing the multitude of network access points. More than 80% of breaches now involve data stored in hybrid environments, according to IBM’s Cost of a Data Breach 2023 Report.

That’s why, to avoid data loss and maintain a comprehensive level of protection across the entire environment, organizations need a blueprint for adopting and evolving their hybrid systems. The right solution enables data protection across workloads, providing the hybrid enterprise with the flexibility to protect data wherever it is today — and wherever it might be in the future.

A growing multitude of organizations in various industries have successfully implemented blueprints of this sort, built on the following foundational considerations:

Cost-optimization: A solution that can span a hybrid environment — SaaS, software and on-premises — and reduce infrastructure to manage and save administrative time.

Air-gapped security: Backup of the most critical data in cloud locations that can’t be accessed through whatever network or networks might be the focus of a cyberattack.

Fast recovery: Flexible, performance-optimized storage combined with the ability to send an air-gapped copy to the cloud for ransomware protection.

Broad coverage: An integrated set of software, appliance and SaaS offerings that span hybrid environments — and can evolve with the organization.

Simple management: Single-pane-of-glass dashboards for monitoring the hybrid environment while reducing management overhead.

Reliability for peace of mind: Leveraging industry-leading, trusted platform solutions rather than unproven point products.

Now’s the time to see it in action.

Ensuring an Insurer’s Data Backup

In Israel, Harel Group is the country’s top insurance and financial services provider, managing a large volume of data and investments. As such, a critical priority for the company is to ensure all that data is 100% backed up and can be restored without any issues.

Harel Group were using a secure solution to reliably protect more than 1.5PB of data in its on-premises environment. More recently, though, it has sought the flexibility and efficiencies of moving part of its infrastructure to the cloud. However, stringent industry regulatory requirements meant Harel could store sensitive data in the public cloud only if it could be backed up and stored as efficiently, securely and reliably as the on-premises data. What they needed was a SaaS solution.

“A SaaS solution takes care of data availability, but not the backup operation of the data,” said David Ben-Eli, system IT infrastructure manager for Harel Group. “We knew from day one that in taking on Microsoft 365, we would need a SaaS solution with good restore functionality that satisfies our business model and strategy.”

And so, Harel designed a blueprint based on a fully managed SaaS platform. The initial stage involved protecting approximately 1,000 of its employees’ mailboxes, which will soon cover more than 5,000 mailboxes.

The SaaS solution also enabled Harel to move its on-premises storage securely to the cloud, which has the dual advantage of reducing infrastructure costs and air-gapping its backups to mitigate the risk of ransomware attacks. “We have peace of mind that our data is secure,” Ben-Eli said. And the entire cost of the SaaS solution “is less than the cost of hiring more people.”

Backing up and protecting a company’s data in a hybrid environment is challenging enough. To be a vendor providing those capabilities to other companies comes with additional challenges.

A Vendor Puts its Data in Order

Evolutio, based in Madrid, is a leading enabler of cloud services that provides more than 5,600 kilometers of deployed networks with 6,100 virtual machines across three data centers. Its goal is to support customers’ digital transformations and foster their agility, flexibility and innovation capacity to optimize their business value.

To meet Evolutio’s needs, Alain Rodriguez, head of services management office, had to find an easy-to-use solution that consumed minimal resources to manage backups and security for Microsoft 365. His blueprint aimed to protect critical data before anything could go wrong.

So, Evolutio chose a single platform to back up and restore data for internal systems. By implementing a fully hosted SaaS-based solution, Evolutio no longer needs to worry about purchasing and maintaining equipment yearly. There is also no upfront investment required and no additional costs for support from the vendor. As a result, Evolutio’s business can grow on demand.

Resolving a Global Data Sprawl

Woodward, Inc. is an American designer, manufacturer and service provider of control systems and components for aircraft engines, industrial engines and power systems. The company has been growing significantly across dozens of global networking sites, with expansion that quadrupled the size of data and backed-up servers.

Virtual machine sprawl ate into company resources while complicating backup operations requiring standardized procedures. Slow legacy servers and apps made it impossible to meet recovery point objective (RPO) and recovery time objective (RTO) targets. And the absence of a coherent, comprehensive disaster recovery plan worsened things.

Topping this off was increased backup storage costs via disk and tape and a need for central management or cross-department visibility into data protection and backup policy compliance. There was no blueprint, in other words.

After trying unsuccessfully to address its needs with various disparate solutions, Woodward decided to replace everything with a comprehensive cloud-based backup and recovery platform. The company switched all global sites to this solution. As a result, Woodward has reduced the overhead of managing their data protection, can consistently enforce backup, restore and retention policies and has unprecedented comprehensive visibility and reporting across the end-to-end environment.

“I used to cringe when I received a restore request since backups would frequently fail,’’ said Loren Leveque, senior manager of IT and system networking. With the cloud-based platform, he said, “I am ready to support the backup, restore and archive needs of our company.”

Supporting Dozens of Manufacturing Plants

Linamar Corporation is a diversified global manufacturing company and world leader in designing, developing and producing highly engineered products. Because the Canadian company supports 61 plants globally, a cloud approach became necessary to streamline efficiency in backup and recovery.

Linamar had recently shifted from Microsoft Exchange on-premises to cloud-based Microsoft 365 for its 7,000+ users worldwide, and the company’s tape-based backup system didn’t support it. The built-in Microsoft 365 data protection was a start, but it couldn’t handle the rapidly expanding demands imposed by Linamar’s global network.

By moving to a cloud-based backup and recovery platform supporting Microsoft 365, Linamar saved the costs and administrative time previously needed for managing tapes. And backup is no longer a full-time job – it’s more like “when you need it, set it up,” said Kristian Smith, Linamar’s manager of technical services and support. Restores can now be handled 100% within the team and take hours to execute, not weeks.

Bringing it All Together

The examples might be as varied and numerous as enterprises worldwide with crucial data to protect. But these and any other success stories all have at least one thing in common: They took a blueprint approach to ensuring that their hybrid environment is secure and sufficiently future-proof.

February 23, 2024
A Guide to Cloud Migration Trends and Strategies

For several years, we have witnessed widescale cloud adoption as a software infrastructure growth and maintenance strategy. Spending on cloud application services (SaaS) continues to grow as monolithic applications are replaced by microservices-based apps and monoliths become relics of the past. In 2021 alone, companies spent $410.9 billion on public cloud services, and Gartner expects this number to rise by 20.4% in 2022 to reach $494.7 billion. But as this movement continues to evolve, engineering leaders preparing their cloud migration strategy must be up to speed on the latest key trends.

Is Migrating to the Cloud Cost-Effective?

For companies migrating to the cloud now, the process is no longer a simple transition from on-premises to remotely hosted servers. Cloud service providers now offer a wide variety of options, and companies run the risk of overspending in the cloud marketplace.

A lack of clarity of their business and product needs or submission to shiny object syndrome can drive companies to spend on non-essential services, especially during migration. It is easy to fall into this trap; companies only realize it after they have committed and try to undo the damage by reversing the process.

Although many public cloud providers offer pay-as-you-go pricing, companies often purchase more services than they use. When companies are unclear about their objectives, such expenditure is more extravagant than the utility. This awareness of cloud spending has encouraged companies to take stock of their needs and expenses, and when they do not add up, to consider partly shifting back to on-premises.

But Isn’t On-Premises a Thing of the Past?

Not yet, but gone are the days of mindlessly unloading entire infrastructures into the cloud. Increasingly, companies are aware of the costs of pulling their data from the cloud.

For many, security and control concerns motivate them to keep data on-premises. The public cloud has its benefits, but private storage has its place, too, especially for some components of your software. All in all, on-premises is here to stay, as companies continue to acknowledge and appreciate its value despite their reliance on public cloud environments.

Why Do Companies Choose Cloud Migration in 2022?

Cloud technologies can potentially deliver faster and better-performing experiences to end users, while innovations are giving rise to new services that cloud vendors can capitalize on. Various use cases are surfacing as companies understand the cloud better and see its potential. They are pushing the boundaries on how they can use the cloud, and cloud service providers are keeping track of the changing nature of the demand.

For example, cloud-based gaming platforms like Amazon Luna are seeing significant growth. The cloud is also of great value to artificial intelligence and machine learning efforts, and these are often intertwined.

The Great Resignation phenomenon also drives some companies towards the cloud. Although some knowledge is needed when moving to the cloud, cloud services offer automation and require less employee supervision in the long term.

The COVID-19 pandemic has also been a catalyst for accelerating cloud adoption, making resiliency a priority. Companies can stay afloat in an emergency if their workloads are moved to the cloud. It comes at a cost, sure, but allows companies to outsource time-consuming responsibilities and focus resources elsewhere. While this was most significant in 2020 and 2021, this logic remains relevant.

Cloud computing is also helping companies improve performance, efficiency and scalability. In addition to AI, the cloud will be instrumental in the development of more powerful augmented and virtual reality apps.

Approaches Defining Cloud Migration Today

The possibility of these approaches or facilities also motivates companies to migrate to the cloud:

Containerization: The process of compiling and storing a service, along with its dependencies, in a container. Due to their small size, multiple containerized applications can run on a server, allowing for easier and cheaper shipping of the service. According to CNCF’s 2021 Annual Survey, containerization is now a mainstream practice, and Kubernetes, for instance, is a heavyweight in this domain, with 96% of companies employing or evaluating it.

Security: In Q1 of 2022 alone, 90% of data breaches had their origins in cyberattacks. Mindful of this alarming trend, companies are factoring security concerns into their cloud adoption strategies. We are also witnessing a shift in businesses’ approach to security via DevSecOps: Incorporating security as a continuous practice from the beginning of the software development life cycle instead of relegating it to the back-burner until the last moment. Additionally, frameworks like secure access service edge (SASE) and customized cloud disaster recovery strategies are becoming essential elements of cloud adoption.

Sustainability: Sustainability is becoming a key component in most business models. Companies are eager to adopt practices and models that reduce their carbon footprint. This impetus is also emerging from business partners and investors who are beginning to employ sustainability as a critical factor when deciding which companies to work with. When a cloud migration is planned carefully, chances are that you will retire certain services in your infrastructure and make decisions about what to migrate and what to retain. By optimizing your migration strategy, you are likely to only run and pay for the services you need, ensuring that your energy expenditure is under control.

Edge computing: Edge computing, a $176 billion market in 2022, emphasizes the importance of building data centers locally; i.e., closer to where they are needed for storage and computational purposes. It solves any bandwidth and latency issues. Improved security is another added benefit of this practice. Edge computing has a bright future as it attempts to compensate for some of the pitfalls of using centralized servers in the cloud.

Cloud-native applications: Cloud-native applications are easier to work with on the cloud, as they are designed and built on the cloud itself, not rearchitected to ensure compatibility with cloud services. When compatibility is not a concern, they can leverage various benefits offered by cloud services. As a result, scalability, flexibility and resilience are built into these applications. With cloud adoption, companies are increasingly in favor of cloud-native applications. This subsequently informs their migration strategy as they decide which services to retire, rearchitect or build anew once the actual migration is complete.

How Does the Hybrid Cloud Fit In?

Hybrid computing is on the rise as it leverages the public and the private cloud to deliver maximum benefit to companies with little to no compromise. The public cloud offers scalability, flexibility and speed, while the private cloud provides cost-effectiveness, security and compliance with regulations. While sensitive data can rest on the private cloud, frequently accessed data can be stored in public servers like AWS and Google Cloud. Investing in a hybrid cloud strategy from the point of migration itself can go a long way in giving companies access to the best of both worlds.

Similar to a hybrid cloud environment, a multi-cloud strategy where companies distribute workloads across multiple clouds put some control into the company’s hands and ensures additional flexibility. By working across cloud services, companies can pick and choose which services are most compatible with their application’s components. These can include services offered by different cloud providers.

Cloud Providers Seeing Growth, and What They are Doing Differently

Serverless cloud environments: Cloud vendors like Amazon, Microsoft and IBM are pushing serverless cloud services. Although these continue to rely on servers (despite the name), companies don’t rent servers or pay fixed charges. Instead, the storage and bandwidth infrastructure scales with the software as and when it requires it. Companies do not need to concern themselves with technicalities and can focus on innovation and improving their existing applications. An added advantage is the provision of safe testing environments that encourage developers to tinker with cloud services and develop solutions for potential failures or outages. Serverless cloud solutions are also beneficial for smaller companies that need not invest large amounts of capital to ensure growth.

Partnerships: To meet the soaring demand for cloud services, partnerships among cloud providers are also on the rise. By partnering with other service providers, companies can offer more services by leveraging the resources and reputations of one another while strengthening their competitive edge in the cloud market.

Industry optimization: Cloud adoption is not limited to software companies. Businesses across industries like healthcare, finance and retail are migrating their infrastructures to the cloud. This variety in demand has encouraged providers to customize their services to meet the specific requirements of each industry. Often, these include regulatory compliance needs in these sectors.

The cloud is only getting bigger and better. You can develop a well-curated transition strategy with the knowledge of current cloud migration trends. Additionally, identifying your requirements at an early stage will go a long way in leveraging the cloud to your advantage.

August 1, 2022
Successful Software Development in a Hybrid Environment

The desire to work from home or from anywhere has only increased as the COVID-19 pandemic lingers. Employees cite a number of reasons why they prefer to skip the office, including cutting commuting times, being more productive, caring for family members and exploring new locations. People are increasingly comfortable with remote interactions and the new technology tools that have sprouted to support the work-from-anywhere trend. On average, employees said they want to work from home 2.5 days a week, according to a monthly survey of 5,000 Americans, while 73% of employees seek hybrid work environments where they have some flexibility in where and when they work.

The rapid spread of the COVID-19 Delta variant also prevented employers from enforcing a full-time return to the office. As a result, the new normal for today’s workforce will remain hybrid at best—a few days in the office and a few days working at home. We are a workforce in transition. For many companies, this has put an unnecessary strain on their digital transformation initiatives.

A question remains: How can companies continue to innovate and execute on their software development initiatives with their employees separated from their teams and offices? Here are some of my recommendations for helping organizations to continue their software development projects in today’s hybrid work environment:

Inclusive Environments

Hybrid workforces require a highly inclusive environment. As a nearshore IT partner that works with hundreds of clients remotely, we ensure that our teams have the same access to managers, HR and the technology necessary to succeed on projects and to productively engage with clients. For example, we have learned that the best way to be inclusive is to take either an all-virtual or all-in-person approach during client meetings. It’s also critical to train your managers to provide the same advancement opportunities to employees regardless of whether they are in or out of the office. From the executive team on down, everyone needs to support employees, regardless of where they are. The same goes for onboarding new employees and partners—a mostly virtual process over the past 18 months. Increasing online mentoring and onboarding platforms to connect employees and to manage client projects while the workforce is hybrid is another significant approach we have taken to ensure everyone feels included and engaged.

Collaboration and Knowledge-Sharing

Employees were abruptly forced to transition away from the office where they were used to frequent impromptu meetings and lunchroom chats. For many, this shift had a negative impact on brainstorming, collaboration and knowledge-sharing and thus, innovation. We give our teams the flexibility to use different technology tools to make up for what they miss most in an office environment—regular, casual human interactions. Our teams use a variety of communications tools for frequent check-ins to connect with clients and their co-workers. As a result, our people say they are more engaged with team members and clients than ever before. They are doing more impromptu chats and “instant” meetings with colleagues and clients as if they were in the office. We also migrated to video conferencing as our communication channel of choice. Video conferencing tools increase engagement and allow team members to join virtual meetings anywhere from their preferred devices. The ability for teams to interact, share and collaborate wherever they are is essential to developing cutting-edge teams and software.

Trusting Cultures

According to the Harvard Business Review, 34% of employees felt that their supervisors “expressed a lack of confidence in their work skills,” and an even more significant number of workers reported feeling that they needed to be constantly available to prove themselves. Sentiments like these highlight a lack of trust, impacting development outcomes. Employers need to trust that their employees are working diligently and consistently throughout the workday or whenever they can successfully complete the tasks at hand. For example, working remotely allows individuals to work when they feel most productive. Organizations need to recognize individual productivity cycles and understand that different team members may be productive during different times of the day, including outside of normal business hours.

Being transparent, forthcoming and open about expectations are keys to building trust with employees. Successful digital transformations and innovative software development are only possible with the right team and people. From a client’s perspective, these are the types of IT partners they want on their side. Technical aptitude and an environment where all employees feel valued, trusted and motivated to do their best are critical for developing effective digital solutions.

Employees have made it clear that they don’t want to be back in the office full time. For many organizations, a return to normalcy centers on developing a hybrid workforce that can work effectively with digital development partners. Creating the right environment and strengthening employee relationships are keys to ensuring software development projects can continue successfully in today’s new normal.

November 15, 2021
How to Avoid the Most Common Online Service Costs

Throughout the last year and a half, most organizations were forced to either create or develop their online service offerings at a rapid pace. Companies had to find alternate solutions to continue day-to-day operations in the transition to remote-first. Low development costs and the wide range of use cases have been primary factors in the continued rise of online services even as enterprises look to move back to the office.

Although the initial development costs are affordable to most global organizations, maintaining those workloads—such as internal self-service or software-as-a-service (SaaS) platforms—is a different story. Many enterprises fall victim to paying unnecessary expenses to keep their online services operating. When calculating the costs of these services, organizations often leave the costs of managing hardware out. In the event they are included, the cost breakdown is not typically accurate.

When transitioning to or enhancing online services, calculating the correct costs can be overwhelming. To avoid overpaying, companies need to properly assess the operational costs of their online services. Here’s how.

Evaluate the Infrastructure

First, determine what type of infrastructure fits best for the online offering or service. A popular trend is the “always-on” model, and with good reason. The success of online streaming services and high-availability digital workspaces encouraged enterprises to adopt this method.

However, it is important to note that these companies are successful with this type of business model because it fits best with their overall product and services offerings. Many organizations cannot thrive in an always-on style because they simply do not need to be always-on. After all, not every service needs to be available 24 hours a day.

If the online service is only needed during typical ‘office hours’ but can remain on standby after closing, the organization still needs to pay for those idle hours. These costs add up and can make for an unpleasant surprise when they show up on the monthly bill. Determine what the cost of using an always-on service will be for the organization before committing to it and weigh if it is necessary. Many times, an always-on service is not needed, and an alternate approach will do just fine.

Pay for What you Need

The more users on a particular platform, the more data is used. Estimating the accurate amount of data use is a vital step in being cost-efficient. In many cases, organizations pay more than the necessary amount because of inaccurate calculations about how much data will be used. It is vital to assess data use regularly to make sure that customers have what they need without the business breaking the bank.

Saving money does not have to equal a poor quality of service. When paying for online services with an infrastructure-as-a-service (IaaS) provider, a business is paying for more than just a place to host its platform. IaaS providers also provide varying levels of support, allowing for organizations to take advantage of additional services at no extra cost. By partnering with an IaaS provider, an organization can experience speed, reliability and security without blowing the budget.

Assess if the Cloud is the Best Fit

A common misconception is that online services are fully maintained in the cloud; however, that is not always the case. Building and testing services may require some operations take place in an on-premises location. An organization needs to evaluate whether on-premises is more cost-effective than developing its service in the cloud. Along with the potential for cost-effectiveness, on-premises solutions can sometimes prove to be more secure. Choosing on-premises or even a hybrid model for highly sensitive data may provide tighter security control.

Maintaining a service in the cloud can potentially transform an online business by offering flexible, scalable and cost-effective solutions. A scalable infrastructure becomes an imperative for a growing business, and with the cloud, services and consumption can grow as the business does. However, organizations need to consider their business requirements and see if their deployment decisions match the requirements for cloud or on-premises.

Evaluate your Total Cost

Providers often give a basic estimate of total expenses, but it is always helpful to ask for your total cost of ownership. Looking at the total cost of ownership ensures clarity between the organization and the service provider. Overall, the most crucial best practice for avoiding unnecessary costs is to be aware of how your organization is spending money.

By assessing the above factors, organizations can cut unnecessary online service costs by only paying for what they need. An organization that is well-informed about its needs and use of resources is in a better position to succeed and scale their offerings—without breaking the bank.

October 28, 2021
Why Integration Must Be Hybrid
Integration is the central piece that ties your enterprise together. The need to integrate has only increased with the proliferation of SaaS applications, IoT sensors and devices, B2B e-commerce supply chains and mobile app development in addition to the vast number of applications that still reside in on-premises data centers which also host mainframe, legacy and custom applications. One of the biggest drivers today is digital transformation—organizations are rapidly trying to become digital enterprises in order to differentiate themselves from the competition and develop new business models to create new revenue channels.

In the meantime, APIs are becoming the standard way of connecting applications, data and devices, and providing services to partners and end users. The API economy is the term used for creating new products as part of an organization’s transformation journey. APIs are also rapidly becoming a new channel for B2B partner interaction. Since APIs and integration are two sides of the same coin, this allows organizations to quickly realize the value of integration to unlock data from different silos, drive consumption of this data and leverage business benefits for the application of this data in various end user and consumer apps.

It’s a Hybrid World

The most common understanding of hybrid is that organizations have applications both on-premises as well as the cloud. Pure cloud integration is a fantasy since most organizations will have applications and systems that have to stay on-premises for a variety of reasons: the cost and risk of redeveloping core capabilities (eg. An ERP application that has been heavily customized for the business or a core banking application that is mission critical), the lack of critical services in the cloud, concerns about security and sunk cost of on-premises applications and data sources (mainframe and legacy applications that just work and will be extremely expensive to rip and replace with a SaaS application).

However, the definition of hybrid is much broader and according to Gartner, such a strategy must address a set of challenges that go across personas, domains, endpoints and deployment models. Lets explain each of these in more detail:
- Personas: Integration development today is not just the purview of IT specialists but extends into ad-hoc developers and business users (often called citizen integrators) who despite not being technical cannot wait for IT to develop integrations for them.
- Domains: Integration has always been a continuum supporting a variety of use cases that go across applications, B2B partners, data (for the purpose of doing analytics) and process (to support automation and orchestration).
- Endpoints: The sources and targets for integration started originally with on-premises, then expanded to the cloud along with the need for mobile connectivity and more recently has exploded with IoT with the proliferation of sensors and devices.
- Deployment Models: This covers the more traditional definition of hybrid and includes on-premises, cloud and hybrid (cloud and on-premises) but is now expanding into a new style called embedded, using a headless deployment model which is required for SaaS applications that need underlying integrations to satisfy their end user requirements.
The Hybrid Integration Platform

A true hybrid integration architecture makes integration available across all environments, for all the personas, overlapping all the domains and connecting all the endpoints. This will span on-premises ERM, CRM and mainframe, cloud and SaaS environments, edge devices and sensors and B2B partners–we call this integrating edge to app.

A key architectural principle in hybrid integration is to allow integrations to be done close to where the applications are in order to reduce latency and increase performance. From an application connectivity perspective, hybrid requires applications hosted on-premises, public cloud and private cloud to all be connected seamlessly so an integration developer does not worry about where they are and only needs to easily wire together the mapping to move data from one application to another.

From a B2B perspective, hybrid requires data from B2B partners (customer and suppliers) to easily be identified, exchanged and processed within the integration layer. From an IoT perspective, hybrid requires that data from sensors and devices either directly or aggregated after analysis is integrated with back-end applications. Finally, all the integrations need to be exposed via an API layer for internal business units and external customers to consume the data in a secure and privileged way through mobile or custom apps.

These requirements have created the need for a hybrid integration platform (HIP) that supports hybrid deployment across on-premises and cloud, democratizes integration development across IT and business users, is versatile enough to support all integration patterns and is extensive enough to integrate everything.

Components of a HIP

A lot of organizations originally solved the integration problem by adopting enterprise service bus (ESBs) and integration platforms. These are still widely in use and in many cases powering mission critical applications for organizations. These integration products solved the application to application (A2A) problem and in conjunction with message oriented middleware (MOM) provided capabilities to decouple publishers and subscribers and allow new applications to be easily added.

However, ESBs are undergoing an evolution since they are considered a monolith and organizations are seeing the need to deploy light weight integrations as microservices. This has led to the emergence of a microservices runtime (MSR) that can be scaled very quickly to meet the needs of the business. MSRs are typically deployed using Docker containers and scale using a container orchestration standard such as Kubernetes and are subsequently monitored using open source tools, such as Prometheus.

A big requirement for deploying microservices is the need for DevOps which provides the discipline to manage the dev/build/test/deploy process using automated techniques. Many of these organizations also adopted B2B gateways to extend the reach of integration to their trading partners for the purpose of exchanging e-commerce documents such as purchase orders and invoices via standards, such as EDI and XML.

A lot of transactions still occur using files leading to the need for a managed file transfer (MFT) offering to securely manage file interactions. These in conjunction with adapters and connectors provide reach to a wide variety of applications and data sources. A newer component is API management, which allows existing integrations to be exposed as APIs for access to a variety of consumers while providing policy based enforcement and security of the underlying services. APIs needs end-to-end lifecycle management and governance to control the creation to retirement process and also drives the need for asset management to track dependencies and relationships and provide impact analysis.

IoT integration is becoming a common use case. An IoT platform along with edge capabilities will allow data from sensors and devices to be easily integrated and analyzed for the purpose of moving to other systems or to take action. In-memory is a key embedded capability for ensuring high performance and scale.

Finally, iPaaS is a pure cloud offering which enables integration in the cloud but in conjunction with an on-premises integration platform, or agent, it can ensure data is seamlessly exchanged between cloud and on-premises with end-to-end visibility and monitoring across the different environments. Here is a quick summary of the components:
- ESB or integration platform (with broad connectivity capabilities)
- Microservices and DevOps
- API management and governance
- B2B and MFT
- Messaging
- In-memory
- IoT platform
- iPaaS
A Practical Approach to Hybrid Integration

A HIP can be extremely powerful but involves a number of components which can also make it overwhelming to tackle all at once. A practical approach is to add components (using a building blocks approach) as the need arises to address various integration use cases.

Most customers already have an ESB or integration platform, so that is usually the starting point for integrating on-premises applications. Once an organization starts adopting SaaS apps then there is a decision to be made whether to simply do cloud integration using the on-premises ESB or to start adopting an iPaaS. A critical factor in this decision process is to follow the general guideline and allow integrations to be done close to the applications. The decision matrix for such a scenario can be described as follows:
- If the use case is mostly cloud to on-premises and most of the applications are still on-premises (80/20 rule) then this can be done within the ESB by adding cloud connectivity options.
- If the use case involves a number of cloud-to-cloud integration needs then it may be worthwhile to invest in an iPaaS for efficiency reasons (there is no need to go from cloud to ground and then back to cloud).
- If the application mix gets switched to mostly being SaaS apps then an iPaaS should be adopted since most integrations will be done in the cloud anyway.
Once you bring together an ESB and iPaaS you are in a great position to start leveraging API management and add B2B capabilities to round out most of your integration needs and start deriving value from these integrations.

Business Benefits

Hybrid integration provides a way for customers to move ahead with critical projects and strategic transformation by exploring more flexible solutions. Not long ago, integration had been painted as a back-office capability with little direct impact on the business. However, integration needs have moved to the front-office and addressing these requirements are key for successful digital transformation initiatives.

The business benefits are as follows:
- Organizations are seeing more demand from customers for a better customer experience. Customers have many choices, the best experience wins the business.
- Businesses need to react faster to disruptive changes by increasing the delivery cadence and deploy integrations faster.
- The technology world is experiencing many disruptions. Businesses need flexible architectures to disrupt instead of being disrupted. They need to be able to implement new projects, scale rapidly to take advantage of short-term opportunities and try new fast-fail ideas to leapfrog the competition.
- Gain benefits of the cloud. There is constant pressure to reduce TCO, use an opex model instead of capex and be able to access and leverage all data available from new IoT and SaaS sources.
- Democratize integrations. IT departments are at breaking point and can no longer meet the needs of the business which means business analysts need to develop integrations on their own in a self-service way, which allows more people to contribute to the company’s goals.
Real World Customer Case Studies

Retail Pharmacy: Our first case study is a large global enterprise with more than half a million employees and hundreds of distribution centers. One of the biggest changes in the company’s history was the merger of two iconic brands. The company needed a global platform strategy to stay competitive and remain ahead of Amazon and other digital disruptors in the retail space, and coined their version of a HIP: Independent Federation Layer.

Software AG provided a solution to standardize global operations—a “cook once, serve many” solution. Rather than buy more tools, the company would invest in a unified set of software capabilities using webMethods HIP to integrate all systems. They set up a 200-person integration center of excellence. All retail stores are being migrated onto webMethods for a mission-critical retail transformation program to simplify and standardize sales and inventory processing. The next phase will be standardized processes for warehouse and order management, replenishment management, financial management and more. With webMethods HIP, this retail pharmacy has the agility to react to market challenges and opportunities.

Transport Company: Our second case study is a multinational public transport company that operates bus, train and tram services in Europe, Canada and the U.S. They needed to lift and shift services to the cloud in order to create a new business offering that could scale easily. They refactored their webMethods integration code base and moved key services to the webMethods integration cloud to enable customers to purchase tickets using mobile and web platforms via third-party websites. They provided secure access to on-premises databases by exposing APIs to the cloud using webMethods API gateway. In the process, they created a reusable ticketing platform that they’re offering to other transportation providers. They now have a new line of business.

— Subhash Ramachandran
September 19, 2019
The Terrain of DevOps is Strewn with Pitfalls

As Gene Kim, one of the leading thinkers in DevOps, once said, “DevOps is not about what you do, but what your outcomes are.” What he’s telling us is that DevOps is about enabling a rapid flow of work that transitions from development to testing to operations, but the bottom line is that it’s about achieving results. Unfortunately, this too often gets lost in modern-day DevOps practices.

In this article, I will discuss five common pitfalls that occur in DevOps if you don’t pay attention to the endgame and how your organization can avoid falling victim to them.

DevOps and Automation: Measuring the Wrong Outcomes

Some people believe that, at its core, DevOps is about trying to automate everything. But ask yourself this: Once you automate, are you really delivering a better outcome?

The answer is not always yes. While metrics such as deployment frequency or mean time to repair (MTTR) are interesting DevOps indicators, they are no more interesting to determining if your team is delivering actual value than measuring the number of lines of code submitted or counting the number of keystrokes by the development team. You measure outcomes by determining a baseline from where you start and compare that with where you end.

We need to understand that DevOps is about much more than automation; it’s about the entire pipeline and how your team moves from ideation to delivery to production. Even large companies with world-class DevOps teams don’t always clearly see the problem and can struggle managing the value stream and putting together multiple pipelines. An anonymous but real-life example of this is an organization I know that had been doing DevOps for 18 months, yet hadn’t delivered anything into production in that span. Are they really doing DevOps? DevOps is a process, but if it produces zero value, it’s not delivering on its promise.

The key is focusing on delivering value and measuring value delivery into production. However, before you can begin measuring value, you have to define what it means to each individual deliverable. Common metrics include the number of story points, actual revenue from product comparison and customer satisfaction. With your clearly defined metrics in place, you can measure value as it gets delivered to the customer.

DevOps and Fragile Environments

One Achilles’ heel in the DevOps process is the pre-production environments where code gets deployed and tested. Automating a delivery pipeline relies completely on code being built and deployed to various environments. Fragile environments mean that the developers and testers are wasting time dealing with problems originating from the environment and not the code itself.

While we wish all environments could be on-demand; the fact is, most are not. Another DevOps expert, Randy Bias, has an analogy about pets versus cattle in describing servers, and the same analogy can be used for environments. If environments are not standardized and repeatable, you have to be willing to move on from it like a farmer moves on from livestock; you can’t hold onto sentimental attachments like we have with our pets. What’s most important is that in no case can an environment be singular in nature.

One element of the solution is to create code and automate, but the key is building up environments that are complete. Every environment needs proper builds, proper data and proper tests validating the environment. Additionally, the automation must have the stability to perform successfully every time. If you have piece of automation that fails even just 5% of the time, that’s unacceptable.

The only way automation works in an environment is if you can trust the environment. When the environment is unstable, it’s like playing Russian roulette: No one knows exactly where the danger lies. It could be in the environment, the code, the data, the middleware … a number of places. When a problem arises, developers are often the last line of defense, but dealing with an issue such as this pulls them away from getting real work done.

Disconnected Teams

On this point, I’d like to share a warning: Disconnected toolchains lead to disconnected teams. The planning, development and testing teams can lack cohesion, and the release and operations teams often struggle to be on the same page. Each of these groups have their own tools and management, but they need to be able to communicate with each other effectively to make things work smoothly. In an ideal world, planning initiatives would flow into features for the development and testing team, which would flow into release pipelines and operational changes. Every team still can speak its own language, but the tools need to be interconnected and unified across the teams.

Mismanaging Hybrid

The term “hybrid” has many different uses in the software development space. Hybrid methodology refers to combining waterfall, agile and DevOps practices. Hybrid environments means your environment is housed in multiple locations such as the cloud, on-premises, virtual or code. There’s also hybrid geography, hybrid architecture, hybrid style—the list goes on.

The key to transitioning to DevOps is properly managing the different types of hybrid. If you can’t manage hybrid delivery, you can’t manage your entire delivery and you can’t improve your delivery holistically. Organizations must learn to manage in a world of hybrid delivery and be able to handle cloud and on-prem, as well as teams all over the planet.

Fixing Non-Constraints

The Theory of Constraints is about pinpointing the bottlenecks in your process and fixing them. Any work that’s not focused on eliminating the constraint will not result in improvement and could be considered a waste of time.

It’s important to remember that if you haven’t fixed the bottleneck, you haven’t improved anything. At the same time, if you’re automating the non-constraints, you’re wasting efforts by trying to improve what doesn’t need improving.

As we’ve pointed out, DevOps does not equal automation. If an organization has messy processes and tries to automate them, they’ll be left with an automated mess. Therefore, organizations will see the best results from automating their constraints and just as important, not automating the non-constraints.

— Jeffrey Keyes

May 13, 2019
Denim Group Awarded Hybrid Analysis Mapping Patents by U.S. Patent and Trademark Office

Issued Patents Will Drive Innovation in Managing Large Volumes of Data Generated by Application Security Testing Programs

San Antonio, TX – October 30, 2018 – – Denim Group, the leading independent application security firm, today announced that the United States Patent and Trademark Office (USPTO) has awarded the company two patents which will provide a method of correlating and merging static application security testing (SAST) and dynamic application security testing (DAST) for web and mobile applications. The official name of the Hybrid Analysis Mapping (HAM) patents are as follows: Method of Correlating Static and Dynamic Application Security Testing Results for a Web Application (Patent #10,043,012) and Method of Correlating Static and Dynamic Application Security Testing Results for a Web and Mobile Application (Patent #10,043,004).

The continued proliferation of websites, web applications, and mobile applications that handle sensitive data makes securing an organization’s application portfolio a major challenge. Effective application security programs utilize multiple types of analysis to test applications for security vulnerabilities, resulting in a high volume of data produced. This increased data can be valuable when it provides deeper insight into vulnerabilities; however, it can also make the problem of identifying areas of concern harder to manage by requiring further manual reviews by the analyst or highlighting large numbers of vulnerabilities and weaknesses that are of low value or priority. Without positive correlation of large data sets, the value of vulnerability data sets is diminished.

Denim Group has implemented the technology from these two Hybrid Analysis Mapping patents into their vulnerability resolution management platform, ThreadFix, in order to help organizations efficiently manage the large volume of data that is generated by an organization’s application security testing program. This technology makes ThreadFix the first platform able to correlate SAST and DAST results without requiring a runtime agent. As a result, organizations report a 71% success rate in matching SAST and DAST results and an average reduction of 15-35% in overall findings. ThreadFix improves the ability of the application development team to identify vulnerabilities found by both testing tools and prioritize them in order of degree to be addressed.

“We are honored to be awarded these two patents by the USPTO to help organizations more effectively manage their application security testing data,” said CTO of Denim Group, Dan Cornell. “By enabling organizations to more accurately correlate the results of static scans with dynamic scans and manage the data that is generated by their testing program more efficiently, we are delivering a significant breakthrough for today’s industry professionals in the application security space.”

October 30, 2018
DevOps Chat: Mark Nunnikhoven, Trend Micro on Hybrid Cloud

devopsy.kinsta.cloud sits down with Mark Nunnikhoven, VP Cloud Research at Trend Micro. We discuss hybrid cloud, hybrid cloud security, DevSecOps and more. Mark is very involved in research on the latest threats and trends in cloud security. This is a great interview that I think you will find very interesting.

As usual, the transcript of our conversation follows:

Alan Shimel: Hi, this is Alan Shimel, devopsy.kinsta.cloud, here for another DevOps chat, and I’m joined today by Mark Nunnikhoven of Trend Micro. Mark, welcome to DevOps Chat.

Nunnikhoven: Thanks for having me, Alan.

Shimel: I hope I didn’t mangle your name too bad, did I?

Nunnikhoven: No, it was perfect. It’s a tricky one. It looks really menacing, but ends up being relatively simple after you’ve heard it a few hundred times, so –

Shimel: Absolutely, very good. So, Mark, I asked you to join us today—I think we had done a webinar and talked a bit offline about, you know, some of the challenges around securing hybrid cloud and, you know, versus obviously people moving stuff to the cloud, people still have stuff in their data center, and what’s good for one may not necessarily be good for the other, but what’s good for both might be an entirely different thing. And I wanted to just spend a little bit of time with you talking about the challenges of securing the hybrid cloud.

Nunnikhoven: Yeah, it’s definitely an interesting topic that I don’t think gets enough attention, so I’m glad we can have this chat.

Shimel: Yep. Before we jump into it, though, Mark, I’d be remiss if I didn’t give you a chance to just let people know, I did mention you’re with Trend Micro, but what is your role there?

Nunnikhoven: Yeah, I’m the vice president in charge of cloud research. So I look at how organizations are tackling security in the cloud, in hybrid environments for, you know, traditional servers and workloads, containers, serverless, sort of anything that’s breaking new ground. It’s a lot of fun and there’s a lot of really interesting stuff happening.

Shimel: Great. So, Mark, you know, I think I started us off by saying there’s people who are making solutions for the cloud, there’s people making solutions for the data center, the ARM RAM. And what’s good for one is not necessarily good for the other, and then, of course, most of the world is living in some sort of hybrid environment.

Nunnikhoven: Yeah.

Shimel: What do we do?

Nunnikhoven: [Laughs] That’s a great question, ’cause, you know, I’ve seen—working with organizations around the world, I’ve seen sort of all of the possible scenarios, I think at least the major ones that people kind of come to thinking might work, and they sort of range from we’re going to force data center processes and controls into the cloud, which is a recipe for disaster. You know, they’re very different environments, to the opposite, of we’re gonna take everything that’s working in the cloud and we’re gonna force it on the data center, to, you know, we’re gonna run two completely different environments in completely different ways, and essentially double the workload. None of those is really satisfactory. Sort of the best route forward tends to be looking at what’s working in the cloud and trying to push a lot of those concepts into the data center. But you still need to make adjustments for the reality that the data center is very, you know, sort of slow and very high level of rigor and very formulaic, and, you know, very well-established. So you do need to make adjustments, but, you know, the goal is to get one way of doing things with allowances for the difference in both environments.

Shimel: Yep. And Mark, as you said, that may be the goal, but, you know, from day one, you obviously—you need a plan to get there. And can you maybe share with our audience a little bit, where do you see the logical steps, if you will, to getting there?

Nunnikhoven: Yeah, and I think that’s a really good way to phrase it, you know, because we can all—we all love the architecture Powerpoints and you go the events and you get real excited about what the eventual design and implementation will look like. But getting there can be really ugly and really messy. I think the biggest thing, and it’s unfortunately the thing that people tend to forget about, is looking at not just the security, but the operations processes and controls that you’re using today, and why you’re using them. And I think that’s the big piece that people miss, is, you know, why am I using something like an intrusion prevention system, or why am I using anti-malware or why do I have this change review board for any sort of operational change I want to make. And once you start to dig into the why you do these things, you realize that the implementation can change, as long as you’re still meeting that why.

So, you know, we put intrusion prevention in place so that we make sure that any time we open up traffic to this server, that we verified it is actually secure web traffic like we’re expecting. Once you know that’s the reason, then you can look and say in my data center, that makes sense to have a big perimeter appliance doing that job, whereas in the cloud, it makes more sense to have something running on the host, doing that same job. So you’re still getting the same answer to why. It’s just the how is different in each environment. So it’s—you’ve got to dig into those, and it starts to clarify what you’re doing.

Shimel: Got it. Mark, what are we seeing—I mean, what—obviously at Trend, you’re probably talking with a lot of customers. Are they coming from the cloud down with their solution? In other words, buying a cloud solution and building—or from the data center up, if you will?

Nunnikhoven: A lot of the time we’re seeing the data center up, simply because it’ll be one team within a larger organization. So we’re talking mainly, you know, traditional enterprise and large governments. And it’ll be one team that’s gone and said we’re gonna push everything and build it new in the cloud, and when they start to kick off that process, they start to get a lot of existing policy and existing culture enforced on them. So they’ll get, you know, specifically the security. They’ll get people saying, well, you need this, you need to make sure that, you know, you go across these boundaries in your design, you’re networking a certain way. So they start to try to take those same designs, which are great in the data center, but horrible in the cloud, and they try to push those into the cloud, and they usually end up failing. And then about six months afterwards realize that they need to take a new approach, because it is a completely different environment.

Shimel: Got it. And, you know what, Mark, I’m a firm believer that at least for the foreseeable future, five, 10 years, hybrid cloud is the—is the dominant, right, the dominant usage pattern that we’ll see from people. Is this yours as well?

Nunnikhoven: Yeah, 100 percent. And for me, it’s simple economics. As much as you want to be in the cloud, if that’s the case, if bought in even, you know, you’ll see it at the major events from the big cloud providers. They’ll pull up big enterprises who are—their CEO or the CIO is, you know, yelling from the top of their lungs that they’re gonna be all in on the cloud. Even in those scenarios, they’re still going to take 12 to 18 months to move out of their data centers.

But the reality is most enterprises have already made a multimillion dollar investment in technology that’s working. It might not be working as fast as they want, but you can’t walk away from that. The cost savings in the cloud, if they’re there, are not that significant that you’re gonna leave millions on the table. So the reality is, you know, for a standard data center life cycle, so like you said, a five to seven year term, you’re gonna be dealing with two environments. And it’s not just that it’s two environments, it’s two environments that are completely different. It’s very much apples and oranges. So you do need a different approach.

Shimel: Got it. And, Mark, I don’t want to put you on the spot, but what Trend Micro specifically, what kind of solutions are you guys, you know, working with customers on?

Nunnikhoven: Yeah, so one of our big push, and we’ll just hit it real brief, because we don’t want it to be a sales pitch at all, it’s just we have a platform called Deep Security, and we built it with the principle of trying to put security as close to the data and application as possible. And because of that, we’ve been able to adapt it for multiple cloud use, for data center use, for the hybrid scenario quite well, because we’ve taken a lot of the principles that work in the cloud and made it so that you can leverage them where it makes sense in the data center. So a lot of automation, a lot of programmability, and a lot of intelligence in the products so you don’t have to worry about the nitty-gritty of dealing with security day to day, unless it’s really urgent and requires you to intervene.

Shimel: Excellent. And, I mean, Trend is obviously not the only one doing this, Mark. When we talk about cloud too, I wanted to ask you this, public versus private clouds, where are you seeing this kind of—you know, are we—you know, to me, a private cloud is—goes hand in hand with hybrid, right? But there are people who are doing public cloud and data center, and that’s hybrid as well.

Nunnikhoven: Yeah, and I find for me, you know, private was a real big push back from a lot of the incumbent data center vendors, and, you know, we’ve kind of gotten out of that hype phase and into the reality of it. And I tend to see what a private cloud is, is somebody who’s taken the data center and adapted a lot of the cloud processes and the ideas behind a public cloud and implemented them within their data center, which can be a really good thing. So you can get on-demand resources, so you just query in API instead of sending out a ticket and getting a bunch of people to do work. You know, getting that accountability, getting that accessibility and that visibility that we’re used to in the public cloud, getting that in the data center.

So I think the ideal hybrid scenario is leveraging private cloud/public cloud. A lot of people aren’t there with their data center, because implementing change takes a long time. There’s a lot of cultural change, a lot of tooling change. So you’ll see them with sort of more the traditional data center approach. But if they want to be successful over the next few years, they need to start pushing more of those private cloud ideas internally, because that will help them have one set of processes and tools across both the public and the private cloud.

Shimel: Makes sense, makes sense. And Mark, what about people, though, who just say, you know what, I’m—I’m biting the bullet, I’m just gonna do cloud, you know, or I’m just gonna do data center. You know, first of all, nothing is forever, obviously, right? You could say that today, but things change. Is the Trend Micro solution, specifically, let’s say, is it one that will work with one, but that scales to the other? Or, in other words, how do we stay out of dead ends?

Nunnikhoven: Yeah, and specifically from us, this is something we’ve been dealing with with our customers over the last few years, because we’ve got customers who are 99 percent in the cloud and 1 percent in a data center somewhere, and the exact opposite. And it really—you know, every culture and enterprise is unique in what their blend and their mix of those environments is. So having the tool be agnostic to that is really important. So, you know, we’ll scale from protecting one system, to protecting 100,000 systems, with the same platform, very, very easily.

And I think there are a lot of projects out there, you know, not just commercial offerings from Trend Micro, but we’re seeing this a lot in the operational monitoring space. So, you know, things like Ryman or Logstaff, which are two great open source projects to help you correlate data, they work equally well in the cloud as they do in the data center, and I think that’s really a big win for people, is that you need to put the assets in the environment that makes the most sense, but you should be able to use modern tools in both. And that’s a real big, important point for people to take away, is that you want to be—even if you’re in a traditional sort of slowing evolving data center environment, you want to be making sure that you’re leveraging some of the great advances we’ve made in security and in operational tools.

Shimel: Excellent, excellent. Mark, we’re coming near the end of our time, as this always seems to go quick. But let’s talk a little bit about the research that you’ve been doing, and just give our audience maybe a little insight. What are you kind of researching now? What do you find really interesting?

Nunnikhoven: Yeah, the biggest area I’m focusing on right now is the rise of what’s been deemed the serverless architecture. So obviously sort of a poor choice of names. There are servers somewhere. But it’s the idea of leveraging a function as a service as something like Microsoft du jour functions or AWS Lambda, where you’ve just got code that you input that runs in a sandbox on someone else’s system and you don’t have to worry about any of that. So scaling and operational tasks are kind of out the door, but these are heavily leveraging SaaS services and you’re sort of picking the best aspects of multiple providers, and stitching it together into one big application. And there’s a lot of really interesting advantages for the business there, because you’re focusing purely on delivering value to your users.

But from a security perspective, now you’ve got multiple parties and systems that you have to trust, that have to work together, that have to share security controls, and then that is normally only one application in a suite of others. So you’ve got serverless applications, you’ve got applications that are running on containers, and then traditional applications. So I’ve been looking at not just the serverless, but how you do you address all of these in a consistent manner, so that you can apply security to the data where it’s being processed.

Shimel: Excellent. Mark, we are butting up against time here, but one last question, and it’s one I frequently ask our guests here on DevOps Chat. If you had to recommend one book to our audience to read, not necessarily the last book you read or anything like that, but one book they should read, what’s your recommendation?

Nunnikhoven: Yeah, that’s always a tough question. I love reading, so I’m always reading three or four books at a time. And, you know, it’s a safe assumption that this audience has already read “The Phoenix Project.” If they haven’t, they should. My latest favorite in this space is called “The Art of Monitoring.” It’s by James Turnbull, and it’s a look at how to implement metrics and measurements around running applications, regardless of where they are. So it talks about logging, it talks about real-time alerting, and it’s a really great approach, in that, you know, it’s always looking at results. So not just collecting data for data’s sake, but it sort of walks you through how all of this stuff should roll up to give your teams some actionable insight on how your application is doing. It’s a really great book.

Shimel: Got it, interesting. Well, Mark, thank you so much for being this episode’s guest, of DevOps Chat. We’d like to maybe have you back on sometime and talk to us about more of the research you’re doing. Continued success to you and Trend Micro, and just thanks again. This is Alan Shimel, for DevOps Chat, and thanks for joining us. Until next time.

August 22, 2016
How to Handle DevOps Microservices (Hint: Carefully)
Given the dizzying amount of best-of-breed tools that can be involved in the development pipeline, a well-written microservice comes to the rescue with just enough code to keep things running. But too much of anything is never good. Here’s how and when to use microservices.

Microservices are all the rage right now: these mini-apps are being used to integrate distributed applications that can be modified more easily. Microservices act like the glue, holding together processes and systems in the DevOps automation workflows. This means faster, more automated cycles, better implementation of continuous delivery and increased visibility into DevOps processes and deployments.

For developers and testers, who generally love the best-of-breed approach of using whatever tool they prefer for the job, microservices allow them to do that by affordably connecting many different open-source and commercial tools in the DevOps pipeline. While some of these tools have built-in integrations to other popular tools, those integrations may not be exactly customized for your needs. Asking the vendor to build custom integrations for you can be cost prohibitive and may not be feasible within the time frame your organization is looking to implement.

So with microservices, development teams have the flexibility to build their own tool stack and integrate everything to achieve full visibility into the development process. Equally helpful, REST APIs are super easy to work with compared with legacy APIs; developers can handle writing microservices without specialized expertise in the products that are being integrated. These are just a few of the extremely powerful advantages of the microservices approach.

Yet as with every other cool technology, there are a few hitches, as follows:
1. Hard to handle. Microservices depend upon vendor APIs, and when those change, the service will break. Then, you’ve got to rebuild the service from scratch. That is a time-consuming task that detracts from the main job at hand: writing and refining code. In an environment with hundreds of microservices, pretty soon, you’ve got developers spending the bulk of their time updating those pesky mini-apps in your devops pipeline instead of building new user features. Costs escalate and timelines slip.
2. Slapdash processes. Let’s face it, when you’re writing a microservice just for your team, you’re going to do it as quickly as possible, thereby skipping a few steps that can make the microservice less fragile. A vendor, meanwhile, writes a micro-service to help hundreds of customers – therefore, it’s got to be bulletproof. The internal approach for integration through microservices can be more prone to breakage. Once one service breaks, there is the inevitable domino effect with other integration points, meaning down time in your development process.
So, now what? It’s possible to make all this a bit easier. First, make sure that you’ve got the economics straight. Will developing microservices as your integration strategy be cheaper (factoring in staff time) than having vendors do it for you? If cost is not the main consideration, do the benefits of having a custom-built DevOps tool stack outweigh the complexity issues including downtime risks when a service breaks? Is there a clear-cut benefit from having a custom integration over taking the vendor’s not-quite-perfect integration? Do the analysis before choosing the microservices path – and remember to tie all this back to business benefits.

Here are some ways to reduce the complexity of microservices:

Go hybrid: In most cases, organizations will find that using a combination of vendor integrations and microservices is often the answer.

Outsource: For business-critical applications, it’s not a bad idea to let an outside development firm handle the microservices portion for you. That will reduce your risk and free up your developers to focus on building products not managing integrations.

Tools and languages: Choose languages for writing microservices that work well with REST APIs, such as Python and Ruby. As well, keep an eye out for tools that can help when you’re doing this in-house, such as Zapier or TaskTop. We expect those automated options to only grow, as companies expand their use of microservices and containers to optimize their DevOps operations.

About the Author/Kevin Dunne

Kevin Dunne is the vice president of strategy and business development at QASymphony. He has a deep interest in the emerging trends in software development and testing. Kevin joined QASymphony from Deloitte, where he managed testing on large government and Fortune 500 engagements delivering ERP implementations and custom software development. He can be found online at LinkedIn and Twitter.
November 2, 2015