The Department of Veterans Affairs is planning to increase its cloud migration and microservices deployment in order to be more flexible and modern.

Indeed, with the pandemic, the agency noticed a 400% increase in remote users and more telehealth visits, from 25.000 per month to more than 40.000 per day. The agency stated that it switch from a legacy of Skype infrastructure capability to Microsoft Teams during the pandemic.

It was reported that they are planning to shift hundreds of applications to the cloud over the next couple of years. Considering the size of the agency, it needs to be careful in its move to the cloud. Still, the Enterprise Cloud Solutions Office aims to migrate about a third of the VA’s 1,000 major applications by the end of the fiscal year 2024.

The agency said it had almost 130 applications in the enterprise cloud today and that it was working with Amazon Web Services and Microsoft’s Azure for its enterprise cloud efforts. It is also looking to adopt containerization and microservices in the coming years.

The post Department of Veterans Affairs to switch to cloud and microservices appeared first on DevOps Online North America.

Contrary to a monolith architecture, a microservices architecture allows its services to be deployed independently by machinery that supports fully automated deployment.

Hence, experts in the industry tackled the rising importance of automated testing for microservices and its future.

What is microservices testing?

A microservice is an autonomous independent service that encapsulates a business scenario, Venkataraman Purushothaman, Automation architect at the U.S. Bank, tells me. It contains the code and state. Usually, a microservice even contains its own data store. Hence, this makes it independently versionable, scalable, and deployable. They are loosely coupled and interacts with other microservices through well-defined interfaces using different protocols. They remain consistent and available in the presence of failure.

Guillermo Toro-Bayona, Software Developer at Nando’s, adds that Microservices is one of many software architecture styles in which the strategy is to have simple, small, and concise pieces of software focusing on solving problems in a particular part of a business domain. These services should be easy to extend, modify, test and deploy in order to increase the speed in which an organisation adapts itself to different changes, caused by either customer needs, new regulations, aggressive business competitors, etc.

Microservices architecture allows organisations to quickly adapt to change and reduce their time to market, by offering a simple and more manageable way to modify the software that supports a particular area of a business model. Usually, microservices go along with a complete strategy of Continuous Integration (CI) and Continuous Deployment (CD), giving the business a flexible way to deploy new versions of services by increasing the cadence of software releases.

Ajay Thakur, Manager Quality Engineering at Publicis Sapiens, also defines microservices as an architectural style that takes every application function and puts it in its own service (provided the function is suited to run as an application) and runs on a container, and these containers communicate over API.

Put it more simply, it is a collection of services that are: loosely coupled, independently deployable, maintainable, testable, and organized around the business feature.

In order to make it clear, let’s take the example of an application (for instance, Amazon), and compare Monolith Vs Microservice. For simplicity, let’s group the website into some basic components like front-end, user profile management, payments, search, etc, as you can see on the figure below:

According to Guillermo, running different types of tests on a microservice increases the confidence of the organisation in releasing software. Indeed, if a service is deployed many times during the day or week, it should be with the guarantee that it will not affect current customers, it will not disrupt business strategies and it will not break other software integration. The only way to increase that confidence in this strategy of continuously releasing software is with testing.

There are many types of tests involved in a microservices architecture. Initially, you can think of some sort of Unit Testing to make sure the service is doing what is expected to do. The microservice functions and algorithms are working as expected with some given input. This is vital to get some confidence that the code is working.

In addition to Unit Testing, you could add another type of test to make sure your microservice is working as a whole, not individual functions or modules in isolation. Integration Testing helps you to test the microservice once all the internal modules are working together. Using mocking tools helps your tests to see how the microservice will react to different integrations and how it will cope with failure and success on those. Depending on the type of integrations you could either simulate failures when trying to connect to a database system over the network or reaching a timeout on an HTTP endpoint of another service, lack of permission on a file system, etc.

Another type of testing is End-To-End Testing, which aims to test the microservice in a bigger picture, testing the microservice as a black box to see if it has fulfilled the business expectations. The microservice and all its integrations are in a controlled environment in which we can observe the behaviour. This type of testing usually covers as many potential flows as possible. A microservice could call third parties, external systems, other microservices in order to solve a particular problem within an organisation. This kind of test verifies the microservice and its integrations are working together to achieve a business goal.

These tests are essential in a microservice architecture in order to give enough confidence to the business that a new release of the service will not disrupt or affect the organisation. There are other types of tests such as load testing, stress testing, contract testing that help to identify other aspects of the microservice and its expected behaviours.

Moreover, Ajay adds that, to effectively test microservices, you must know the concept of ‘TEST PYRAMID’. It’s a great visual depiction of different layers of testing with how much testing on each layer.

The original test pyramid had only three layers (Unit, Service, and UI tests), however, it is not appropriate in the current world of microservice testing and, thus, can be misleading. That is why, it is important to understand your test requirements and build the pyramid based on that, covering all aspects of testing. Hence, here is the test pyramid the most widely used in the industry:

Venkataraman points out that microservices are fine-grained and self-contained in the nature of APIs, these are independent components and are ready to be tested in isolation.

Indeed, there is a requirement to reduce business risk due to early testing of interfaces and their interaction in absence of UI availability. As several new services are been built to support interaction with existing services, there is a need to test all the services across multiple interfacing applications. With microservices breaking things down into components that are easier to design, manage, and deploy, there are a lot more of these smaller APIs to test. Microservices Architecture is for applications, or their components, that are likely to change frequently. Hence, there is always a need to test these services before moving to the next testing phase.

Microservices architecture allows multiple customers to connect from multiple channels (WEB/Android/iOS), this arises a need to test the Microservice endpoints thoroughly for different source systems.

The best approaches 

Given the importance of testing in a microservices architecture, testing is vital in different parts of the whole releasing cycle of a microservice.

Indeed, Guillermo underlines that the releasing cycle is usually part of the strategy of Continuous Integration (CI) and Continuous Deployment (CD) pipelines. Within these pipelines, the whole process of compiling, packaging, and installing a microservice is orchestrated in different steps.

Unit Tests are essential once a new version of the software has been released by a developer in order to make sure the code is correct. No new microservice artifacts (such as container images, packages, libraries, etc.) should be produced if the Unit Tests are failing. Integration Tests could also be included as part of these initial steps in order to verify different integrations via mocking tools. Once these two types of tests are successful, the microservice artifact could be released for the next steps in the pipeline.

End-to-End Tests require that the artifact of the microservice is available for testing in a controlled environment where other integrations within the infrastructure could be tested. Once the End-To-End testing is successful, it is a good indicator that the microservice is working as expected. The Continuous Deployment (CD) will be in charge of installing and deploying this new microservice artifact with a good degree of confidence.

For Ajay, here are the best approaches according to the various types of testing:

Venkataraman shares this figure to explain the best approaches to test microservices:

Why would businesses adopt automated microservices testing?

Industry leaders (like Netflix, Amazon, Apple Care, etc.) and many other businesses had and have recognized the need for continuous and sustainable innovation, and which is why they’ve either already moved away or moving away from monolith applications as it slows down their plan of incremental and fast improvements to applications in response to market demands.

Indeed, as Ajay points out, with a monolith, any new feature added to an application requires substantial time and resources to build and deploy, thus shunts the ambition of fast innovation and implementation.

On the other hand, Microservice offers the capability to construct applications with a functional approach with multiple distinct services rather than running everything inside one single application.

Besides, Guillermo emphasises that organisations want the software to support their strategies by solving complex business problems. Microservices help organisations to solve those problems with many small pieces of software working altogether. Changing a microservice could affect the way those complex problems are solved. Testing is one of the strategies that organisations have to get a good degree of confidence on how changes in microservices will not affect or disrupt an important part of the business. Testing is then a key factor in a microservice architecture.

However, Venkataraman warns that going for this approach might not be for everyone. Indeed, he points out that due to distributed deployment, the volume of testing can be high, and the test team might have to deal with the complexity of a distributed system.

Moreover, he continues, this architecture brings additional complexity as the tests have to mitigate network latency, and deal with a variety of message formats as well as load balancing. The increased number of services may also result in information barriers and in duplication of effort.

Thus, he recommends to businesses automate from day one in order to build resilience and get teams moving fast. By automating the release process, you will achieve frequent releases and get codes to flow freely through continuous integration pipelines. He also advises a lot of groundwork, communication, and cooperation between different teams in order to better handle use cases.

The benefits…

According to Venkataraman, automated microservices improve fault isolation and eliminates long-term commitment to a single technology stack. Besides, it can also make it easier for a new developer to understand the functionality of a service as well as allow independent scalability and deployment, which are sure to be more resilient.

For Ajay, the biggest advantage of microservices is that it’s easily deployable (independently) and maintainable (with the right infrastructure set up).

With microservices test automation, you can have:

• Feature-focused design and continuous delivery: It gives the ability to break down an application’s large number of services into smaller, distinct parts, which enable teams to easily work on one part without affecting the others. Thus, it speeds up the CI/CD process.
• Faster time to market: Decoupling of services gives enormous flexibility to teams to innovate and add new features which can be easily developed, tested, and deployed
• Improved scalability: As services are decoupled, it’s easy to horizontal scaling each component independently in case of high demand. Unlike monolith, you won’t have to scale up the whole application
• Increased Resilience & Security: Unlike monolithic architecture, where a single failure affects the whole application, microservices limit the blast radius and easy to recover. Similarly, a security breach in one microservice does not impact the security of other microservices
• Multiple services-Different Platforms: With microservice, different services can be easily developed on multiple stacks and deployed on different platforms

Guillermo points out that testing microservices is definitely a good thing to do. Testing will help to increase the level of confidence in how changes to isolated services will be nicely integrated into the whole digital strategy.

It will also give the organisations more confidence to change and adapt their business rules quickly by offering new products to their customers in a fast-paced challenging environment, without affecting or disrupting existing customer or other systems integrations to support their business value chain.

…And the challenges

The co-founder and CTO of Contino, Benjamin Wootton, says that “microservices are not a free lunch”.

Indeed, Ajay emphasizes that microservices popularity is primarily because of the ongoing trends such as Cloud, DevOps, and Continuous Delivery coming together as enablers, backed by the great work done by Netflix, one of the pioneering case studies in recent time. Therefore, although microservices have lots of significant benefits, it is vital to understand the complexity it brings to the table with ‘managing these services and orchestrating business processes with it’.

Here are some of the complexities of Microservices implementation:

• Operations overhead: Monolith application can be deployed to small application server clusters, but with microservices, you will need cluster for failover/resilience for each service, followed by seeing up load balancers and messaging layers between the services, and all of it needs high-quality monitoring and operations infrastructure
• Strong DevOps Skills Required: Operations challenges of keeping Microservices up and available mean you definitely need highly skilled DevOps and automation skilled development team
• Overhead of component management and Release risk: In a Microservice world, a simple change might end up require changes to many different components, all needing to be released in coordinated ways. Thus, releasing one new feature might force you to release many other services as well, and adds the additional release risk
• Distributed System Complexity: With a distributed system, you will have to reckon Network latency, unreliable networks, asynchronicity, versioning, varying loads, etc. which is not there with a monolith

For Venkataraman, the challenges are that:

• Large numbers of microservices are difficult to orchestrate,
• Understanding, managing, and testing dependencies is difficult,
• Software patterns (encapsulations and such) do not provide a uniform service abstraction,
• Message flow increases with the number of microservices and hampers performance,
• Service interface versioning needs to be managed for multiple services.

The different types of tests require a big effort from the engineering and technical team. However, Guillermo warns, a robust testing strategy is not only affecting technical people within an organisation. It will require product owners and different stakeholders to get involved with different inputs on how the microservices should work in a given scenario, how the whole digital strategy should be affected by one change in a microservice.

These inputs will help to have a clear high-level picture of the microservices within the organisation and how all of them support the business strategies. Hence, it might be difficult to get all of these inputs from different areas of the organisation.  It might also require a good amount of time and effort to create a robust testing strategy in the organisation and mix it up within the Continuous Integration and Continuous Deployment strategies.

The future of automated microservices testing

Ajay believes that it depends completely on the growth of adoption of Microservice implementation in the Industry.

According to a survey conducted in 2018 by Bernd Rücker about digital transformation initiatives, 63% percent of 354 questioned enterprises have shown an inclination of getting into microservices. Tech giant Netflix was one of the trend seers of the microservice implementation, and later on, other companies like Amazon, Uber, SoundCloud, and eBay followed the footprints of Netflix. Former CTO of eBay, Steve Fisher, once said eBay utilizes more than 1,000 services.

Similarly, Google trends also suggest that interest in moving from Monolith to Microservice has grown steadily through 2018 all mid of 2019, and then it peaked in Jan 2020. However, there was a small dip late in the year 2020 which is likely to go up again in the coming years.

For Ajay, as the adoption increases, the adoption of automated microservice testing will play a crucial part in the coming years for the testing industry.

Venkataraman thinks that improvements in software architecture have led to fundamental changes in the way applications are designed and tested.

Hence, making sure that the required amount of testing is focused at the right time, with the most suitable tools, would ensure that organisations are able to deal with testing in such an environment and meet the demands of the customer. A consumer driving approach is suggested as it is a better way to mitigate risk when services are exposed to an assorted and disparate set of customers and it further helps to deal with changes without impacting the customer.

Guillermo believes that adapting business digital strategies quickly will give an advantage to an organisation to reduce its time to market, to put in place new products and services before its competitors, or adapt quickly to new regulations.

All of these fast pace changes need to be supported by a flexible and robust digital strategy that gives confidence to organisations on adapting fast. Testing within a microservices architecture is one way to achieve a high level of confidence in adapting your software to support your business strategies.

Special thanks to Guillermo Toro-Bayona, Venkataraman Purushothaman, and Ajay Thakur for their insights on the topic!

The post The importance of Automated Testing for Microservices appeared first on DevOps Online North America.

Microservice architecture is a distinctive method of developing software systems that seek to focus on building single-function modules with well-defined interfaces and operations. This trend is slowly gaining in popularity, especially as many companies are adopting Agile and DevOps methodologies.

Hence, we talked to experts in the industry to share their insights about migrating to a microservices architecture.

Why migrate to a microservices architecture?

First of all, let’s explore why, according to them, should businesses migrate to a microservices architecture.

Mike Skaife, Principal Software Engineer at Jaguar Land Rover, starts by telling me that there are plenty of great reasons to migrate from a monolith to a microservice architecture.

Indeed, he says, if you’re finding that you are struggling to scale your system appropriately, or if you’re finding it’s increasingly difficult to make changes to your application and respond to user demands, microservices could be the answer.

‘As the technology and tooling to enable microservices architectures keeps on maturing, the barrier to successful entry into this space is lowering all the time.’

However, Mike warns, you should still tread carefully as microservices are not the silver bullet they may often seem.

Moreover, Guillermo Toro-Bayona, a Software Developer at Nando’s, thinks that microservice architecture allows businesses to have more flexibility in how all the different systems work together to resolve complex business rules.

Usually, for a very complex problem one of the strategies is divide and conquer, he says. So, this strategy helps to have multiple aspects of the problem that could be tackled separately.

‘Each microservice should be focused on solving a particular area of the problem.’

In the end, all the microservices will be part of a big architecture resolving complex problems by chucking them into smaller workable units.

For Venkataraman Purushothaman, Automation Architect at U.S. Bank, the rapid digitization is causing substantial shifts in client expectations across businesses. Hence, many are struggling to adapt to this accelerated change. As a result, many industries are aggressively pushing IT to cut delivery time, reduce cost and improve quality – all simultaneously.

He highlights that microservices architecture (MSA) has emerged as one way to address these challenges. MSA describes a new way of designing software applications as suites of small, loosely coupled independent services.

While there is no precise definition of this architectural style, he continues, these architectures encompass certain common characteristics around the organization, business capability, automated deployment, intelligent service endpoints, and decentralized control of languages and data.

‘Like their predecessors, they bring their own set of unique challenges that should be addressed upfront to prevent the architecture from turning into a tangled mesh of point-to-point communication paths.’

Achieving a successful migration

In order to achieve a successful migration, Guillermo emphasizes the fact that you need to first identify which parts of the business could benefit from a microservice architecture.

Indeed, sometimes we have monoliths pieces of software that try to solve everything, and it does a good job. However, when the problem evolves is a bit more difficult to get the monolith to solve the same problem.

He points out that changing the monolith is not as easy as it could affect other areas as everything is in one place, so a single change could affect the entire business. With a microservice architecture changes to smaller pieces of software are dealt in a better way. Identifying those areas where the monolith could be split to cut a small dependency is a good candidate to start the migration to a microservice architecture.

Hence, if you’ve decided that a move to microservices is the right thing to do, there are a number of pre-requisites that are important to have in place to enable a microservices approach to work effectively.

According to Mike, these are the following:

• Continuous Integration and Delivery – when your system is made up of multiple different microservices, and you’re planning to make changes much more frequently, it’s important you have a really solid build, test, and deployment process in place which is ideal as an automated as possible. Managing change across multiple microservices in a manual way gets very complicated and time-consuming very quickly
• Containers and Deployment Environment – you will probably want to be working with containers, which is very different from deploying a monolithic application onto a single server. You should be familiar with things like 12 Factor principles, have an environment where you can deploy and manage containers, and also then consider things like security and how that changes in a containerized environment
• Monitoring and Observability – a monolith is simple enough to understand, you can follow transactions within a single application and just about make sense of log files. But a microservices architecture is a distributed system and exponentially more complex to understand. How do you know where the root of an error is? How do you know which part of a system is causing a bigger issue? Good monitoring and observability toolings such as log aggregation and distributed tracing are essential to be able to understand your system more completely
• Testing – similar to the operations side, it’s also key to have the right approach to testing. You need to test each individual microservice, the integrations between them, and the end-to-end system and user journeys as a whole. This again needs to be as automated as possible to be effective
• Integrations and Versioning – when you have multiple microservices and multiple teams working independently, you need a solid approach to helping them work together as part of one overall effective system. That might mean API contracts in place, a centralized event stream, or some other design. Similarly, you need to have an effective solution to managing what version of each service is running in each environment at any time
• Architecture and Domain-Driven Design (DDD) – although following a Domain-Driven Design approach isn’t essential, you do need to ensure your microservices are appropriately sized and scoped, that you’ve got the right boundaries for each microservice based on business domains, and that the integrations between them are designed appropriately

Venkataraman adds that microservices are a method of developing software applications as a suite of independently deployable, small, modular services in which each service runs a unique process and communicates through a well-defined, lightweight mechanism to serve a business goal.

He highlights that microservices characteristics include the organization of a logical block of functionality around a specific business capability, programming language agnosticism, and decentralized control of data.

Hence, each microservices project will have its API interface and implementation classes, its own data persistence and management module, client libraries required to efficiently communicate with other microservices, and the operational governance infrastructure. It may also include the client classes required to connect with back-end resources.

The benefits of microservice architecture

Microservices can bring a lot of advantages when used appropriately.

Indeed, Mike states that moving from a monolithic architecture to multiple separate microservices enables teams to work more independently. Teams can be built around specific business domains or value streams; engineers no longer need to understand the context of an entire system in their heads which helps with cognitive load.

Besides, he continues, it allows you to scale parts of your system independently based on need as well. For example, at Jaguar Land Rover, they may often need to scale one part of their Software Over the Air (SOTA) platform if they’re launching a software update campaign for a particularly large number of vehicles at any one time, but they don’t want to scale the whole system because other areas aren’t as impacted.

Similarly, if you’re an e-commerce organization you might want to scale up some of your user-facing services during Black Friday, but the parts of the system that deal with deliveries can still churn along at a lower scale. That’s important from a cost perspective as it’s much more effective to scale up small parts of a system than a giant monolith.

Moreover, he adds that technology choices will become more flexible. You can build different parts of the system with different technologies as appropriate. For example, Jaguar Land Rover has a part of their system which is well suited to relational data so they use MySQL as the database, but other areas work more effectively with something like MongoDB.

‘With microservices, teams are able to make those independent technology choices, as well as giving individual microservices control of their own data in a more granular way.’

Finally, Mike emphasizes that microservices allow you to have more flexibility. You can better react to users changing demands when you’re able to limit that change to a smaller independent part of the system rather than having to work with a fragile and tightly coupled monolith.

According to Guillermo, a microservice architecture brings flexibility – easier to adapt your platform to solve constantly changing problems in your business domain – and maintainability – easier to keep a single focus for a single piece of software.

Besides, he continues, adding changes or fixing features is becoming easier if the scope of one microservice is well established.

For Venkataraman, there are a few benefits to consider including:

• Improves fault isolation: larger applications can remain largely unaffected by the failure of a single module.
• Eliminates long-term commitment to a single technology stack.
• Makes it easier for a new developer to understand the functionality of a service.
• Independently scalable, resilient.
• Independently deployable.

The challenges

Microservices are certainly not a silver bullet, and not some magical solution to all your problems as they are often sold, such as Mike tells me. This is why he emphasizes the need to move to a microservices architecture only if it will truly benefit the organization.

There are a lot of challenges to consider according to Mike. Distributed systems are one of them. Indeed, he says, they are complex to test, complex to deploy and manage, complex to understand as a whole. So, you need to not underestimate the increasing complexity.

Teams also often end up with something more like a ‘distributed monolith’ than truly decoupled microservices, where they effectively have a collection of smaller but still tightly integrated services, he continues. That leads to teams getting into a mess where they can’t deploy one service independently without having to also deploy a few others, or where a change in one service frequently breaks functionality in other services. You can thus end up with the worst of both worlds: the complexity of working with separate services but none of the advantages that a loosely coupled architecture would bring.

Moreover, another important aspect that is often overlooked until teams start working with microservices is the developer experience. It’s usually easy enough to run your monolithic application on a developer’s laptop, but what about trying to run 10s or 100s of microservices on that same laptop? Developers get frustrated as their machine grinds to a halt which interrupts their flow when working with TDD, or maybe it’s just not even possible to run the whole system on one developers’ machine.

Finally, the last concern is technology sprawl. It’s great that each team can use whatever technology is appropriate to build their microservices, but you do still need some kind of constraints. Standardization is important to enabling teams to learn from one another, reuse code where appropriate, and so on. Hence, he advised to not use Java and .Net for example, pick one and encourage teams to adopt one.

Similarly, Mike recommends, with databases, don’t use MySQL and Postgres and SQL Server, try and constrain and pick one if you can. Some teams talk about the concept of a ‘golden path’, a tech stack that is widely adopted across the organization, where support and expertise are available in the organization, to encourage some level of standardization across teams. Teams can still go their own way with other technologies, but they’re on their own if they get stuck with any issues.

Venkataraman lists a few challenges to migrating to a microservices architecture:

• Large numbers of microservices are difficult to orchestrate.
• Understanding, managing, and testing dependencies is difficult.
• Software patterns (encapsulations and such) do not provide a uniform service abstraction.
• Message flow increases with the number of microservices and hampers performance.
• Service interface versioning needs to be managed for the multiple services

Finally, Guillermo states that complexity is one of the greatest challenges that come with microservices. Indeed, great power comes with great responsibility. Microservice architecture brings many pieces of software trying to work all of them together to try to resolve a problem.

Monolith solutions were “easy” to do housekeeping as all the different resources associated are in one place. Microservice architectures, on the other hand, bring many pieces with many other problems like latency, security, communication, networking, etc. that will add to the task of maintenance of the IT infrastructure.

Will more businesses adopt a microservices architecture in the future?

Mike does believe that more and more businesses will move to microservices. As compute resources get cheaper and cheaper, and the ecosystems around technologies like Kubernetes and Istio continue to mature and abstract away more of the underlying complexity, combined with advances in the distributed systems monitoring and observability space, more and more businesses will feel confident in moving to this approach.

He also tells me that, as long as there is a hype around microservices, and engineers see it as the current cool thing to do, adoption will continue to increase. This is obviously not a solid reason to move to microservices, so it is ever more important to make sure this is appropriate for your use case.

Yet, he recommends avoiding adding unnecessary complexity before you truly need it. He advises to not do it only because it feels like everyone else is. You need to be pragmatic, make sure you’ve got all the right practices in place, then consider making the leap.

Guillermo also thinks that businesses will adopt this architecture style more and more. Some businesses are struggling to keep up with a very competitive market, which requires being very fast in delivering your products and/or services to your customers to reduce the time to market of the business strategies and be more competitive.

Having an IT architecture that supports that environment is definitely the way forward, he continues. If a business is not adapting to these and keep most of its critical systems in a monolith approach, offering new services to customers will be at a very slow pace and it will impact the sustainability of the business.

‘Microservices will help to be faster in adding value to business strategies.’

Finally, Venkataraman highlights that there is a lot of hype around microservices today. The modern systems architecture idea, which can provide small services with full lifecycle control, is here to stay. Developers deploy only the services that are needed as part of a rollout, update them in place, spinning up additional instances as required.

He believes that businesses will establish cross-functional teams working on each microservice, delivering the same business capability across the enterprise, leveraging their inherent domain expertise in that business capability rather than “reinventing the wheel” within each system boundary.

Special thanks to Mike Skaife, Guillermo Toro-Bayona, and Venkataraman Purushothaman for their insights on the topic!

The post Migration to Microservices Architectures appeared first on DevOps Online North America.

Although microservices are rising in popularity, with 66% of Java developers declaring that they are actively transitioning to or currently using microservices, they are however encountering many challenges with performance and redeployment.

Indeed, one of the main problems seems to be deployment times. 59% of developers said to experience redeploy times over four minutes, while 20% said have redeployed times greater than 10 minutes.

This could be explained by the fact that microservices are running on remote virtualization machines. Another explanation could be due to the growing number of applications developers have in a primary microservices environment.

Even though microservices provide faster and more reliable delivery of complex applications, the survey proved that developers still need solutions to eliminate long redeploy times.

The post Java developers facing many challenges while using microservices appeared first on DevOps Online North America.

The company has a microservices-based architecture that will be able to take complete advantage of Google Cloud capabilities. This will include more agility to launch services quicker, more scalability for cost-effective growth with customers’ businesses and support for complex use cases, and finally, better extensibility that futureproofs platforms into the best technology solutions, as well as product features that drive innovation and deliver on customer acquisition, retention, and revenue.

By combining Firstlight Media’s ability in solving complex issues for operators with the scale, reach, and tools of Google Cloud, the company will enable video providers to capitalize quickly and efficiently on new market opportunities by delivering AI/ML-powered personalization and monetization.

Moreover, customers will be able to leverage Firstlight’s OTT headend in San Diego and digital expertise in the media and entertainment industry so as to have more control over advertising and subscription.

This partnership with Google Cloud will give many options to the company for new services that can better benefit the consumers. Indeed, they will be able to leverage three resources: its cloud-native platform, Google Cloud’s platform, and the technology of other Google Cloud partners.

Hence, this will lead to more opportunities that will maximize the long-term value of each subscriber.

The post Firstlight Media to collaborate with Google Cloud appeared first on DevOps Online North America.

The survey also stated that containers are becoming a very popular app with 34% of participants indicating that they were using containers in their production environment. In comparison, only 15% of respondents used serverless and 7% service discovery.

These findings then prove Gartner’s prediction that 75% of global organizations will have containerized applications in production environments by 2022. There is an important shift to microservices‑based apps, where companies want to build platforms with better resilience and quicker deployment abilities.

Moreover, the research revealed that 14% of participants are looking to adopt service meshes in the next year, which is 50% more than nowadays.

Thus, it also stated that the public cloud remains the most used infrastructure option for modern app tools as well as Infrastructure-as-a-Service, serverless computing, and private Platform-as-a-Service. There is a progressive shift away from on-premises load balancers towards more software-based load balancers.

Yet, there are still challenges. Indeed, 50% of respondents are concerned about security while 39% about reliability and availability, and 34% about performance.

As a result, it is likely that API gateway management will increase up to 22% as predicted in 2021. Therefore, organizations will start to invest more in solutions like WAF and service delivery.

As microservices management keeps on growing, there is going to be more investment in open-source container orchestrators and API management tools. Associated technologies will then also be increasing.

The post 2020 led to a rise in global microservices adoption appeared first on DevOps Online North America.

Moreover, the survey also stated that contributors had no intention of spending more time on security. Indeed, they declared that dealing with security issues was an uninteresting chore and insufferably boring process.

It was then concluded that there was a need to find a new approach to security in order to improve the practices all the while limiting the burden on developers. Indeed, a report from the Linus Foundation and Laboratory for Innovation Science at Harvard urged developers to dedicate more time to security matters, especially as the economy is now more reliant on open-source software.

The report suggested encouraging businesses to spend more efforts in identifying and addressing security issues themselves. Another way could be to have developers trying to rewrite portions or entire components of FOSS projects that could be vulnerable, instead of mending existing code.

It was also found out that the most requested tools from contributors were bug and security fixes, free security audits, and easier ways to have security-related tools to their continuous integration pipelines.

The report stated that developers were mostly interested in finding features, fixes, and solutions to the open-source projects they were working on. As our economy is reliant on free and open-source software, it is vital to understand contributors’ motivation in order to get secure infrastructure and systems.

The post Open-source developers to spend less time on security issues appeared first on DevOps Online North America.

How is Microservices relevant in DevOps?

DevOps works towards continuous monitoring, testing, and deployment of software. Microservices are inherently modular as they are intended to perform a single function. Modular software fits easily into the DevOps structure; thus, incremental changes can be made without difficulties. A single microservice should be able to be easily upgraded, built, tested, deployed, and monitored. DevOps fits perfectly into a similar structure. If a project is employing a microservices-based structure, DevOps speeds up the delivery time and quality simultaneously.

Moreover, DevOps practices entail the idea of breaking large problems into smaller pieces and tackling them one by one as a team. Microservices are thus relevant in DevOps as it uses small teams to create functional changes into the enterprise’s services. Microservices are all about enhancing the implementation and collaboration of small teams in a relaxed environment.

This less complex environment allows continuous delivery pipelines to maintain a steady flow of deployment. Similarly, containerized microservices enable a quicker deployment and built-in functionality, thus allowing the new services to be immediately operational on any system.

Automated operation enhances the microservice approach and creates a more adaptable and easily scalable environment where deployments are performed rapidly. Combining DevOps and Microservices into development and testing will increase the output of teams and the quality of the services.

DevOps and Microservices in Agile development

Furthermore, DevOps and Microservices approach share similar organizational structures and development cultures as well as have a common interest in cloud-based infrastructure and automation. They both have a similar desire for development, speed, and scalability, which all fit into agile development.

The adoption of agile methods also led to the evolution of concepts supported microservices: Continuous Integration (CI) and Continuous Delivery (CD). CD brings quicker changes to production by using a quality-focused ideology, which speeds the deployment pipeline.

DevOps and Microservices: Working for Change

Having a microservices-based architecture leads inevitably to change that is often well received by those creating modern applications. These changes allow an increase in productivity at an impressive rate and deliver solutions more rapidly to those demanding flexible, scalable applications.

Microservices bring some benefits to DevOps fields, such as deployability – increased agility which leads to short build, test and deploy cycles -, reliability, availability – shorter time to deliver a new version -, scalability, modifiability – more flexibility to consume new frameworks, data sources and other resources -, and management- smaller and more independent teams.

Conclusion

Therefore, Microservices bring more productivity to DevOps by supporting a common toolset, which can then be used for both development and operations. This toolset can establish common terminology and processes for requirements, dependencies, and problems. All of this making it easier for DevOps to operate and fix a problem. DevOps and Microservices work better when they are used together.

The post How can Microservices benefit DevOps? appeared first on DevOps Online North America.

This is an overview of trends that have gone before and a prediction of what we think needs to be kept in mind for 2020.

Highlights of 2019:

Low-code

Low and no code is giving firms the ability to develop software by using minimal, or even no code whatsoever, hence its name. Ultimately, low code is about making coding accessible for all. But, although this type of coding was revolutionary when it was first developed, and has seen lots of traction throughout 2019, a lot of companies have seen the benefit it can have and are catching on to using it themselves.

On the topic, Nick Ford, chief technology evangelist at low code company Mendix says, “The thing about low code, is the problem it’s trying to solve: software development is hard, it’s difficult to do. It’s highly complex and highly skilled. So, what low code is trying to address is two things: to abstract you away from that underlying complexity and make it simpler using visual models, the kind you use to drag and drop; to address the collaboration problem inside organisations.”

AI and automation

Artificial Intelligence is more than having its day. It’s having its decade and no doubt, probably its century.

At the beginning of the year, Marlene Spensley, application optimisation practice lead, Nuvias wrote: “Artificial intelligence is already starting to facilitate predictive analytics and coding to replace manually intensive tasks with intelligent insights, recommendations and automation.”

Therefore, AI needs a definite 2019 mention, but as it will continue to grow in automation (along with most other types of tech, too), perhaps this is more becoming a way of life, rather than a ‘trend’.

Predictions for 2020:

Multi-cloud

Towards the end of this year, Multi-cloud is being heard about more and more. And the further that it is heard about, the more questions that are being asked about it. What is multi-cloud? How does it differ from just the cloud? How does one migrate to multi-cloud?

Well, luckily, the additional questions that are being asked about multi-cloud, the more answers that professionals are giving.

In discussing why companies are adopting multi-cloud, Mark Pidgeon, Vice President Technical Services at Sumo Logic , says, “Businesses want to keep ahead of their competitors and retain control over their infrastructure plans.” Adding, “In practice, multi-cloud is still in its early stages…currently, around nine percent of companies are running multiple clouds…. While multi-cloud deployments are still in their initial stages there is a strong correlation between this and use of Kubernetes”

A prediction in the coming year is that multi-cloud will start to dominate DevOps practices and integrate with well-known cloud providers.

Microservices

Although microservices aren’t particularly new to this year, they do seem to be growing in popularity and can highly develop DevOps methodologies when used correctly.

“Realising the full potential of modern databases; microservices; AI technologies; and edge computing – such as in mobile apps and IOT – to name a few, requires serious thinking. Architects are tasked with making the right technology choices and picking the right vendors that will guarantee their initiatives’ success.” Says Ravi Mayuram, SVP of Engineering and CTO, Couchbase in discussing the recent findings of a survey about digital transformation.

Digital transformation

Digital transformation has got to be the phrase of 2019! From major software organisations to growing start-ups, most firms are having to adapt to digital transformation in some sort of way. In fact, one surprising piece of information coming out of this trend is that due to the pressure growing pressure firms are feeling, many places are actually struggling to adapt to this change.

According to another report from DevOps company Couchbase, 86% of company heads admitted to struggling with taking digital services further than they would like.

However, this does not mean that adopting digital transformation going into 2020 is impossible.

“Digital transformation has reached an inflection point,” said Matt Cain, the CEO of Couchbase. “At this pivotal time, it is critical for enterprises to overcome the challenges that have been holding them back for years. Organizations that put the right people and technology in place, and truly drive their digital transformation initiatives, will benefit from market advantages and business returns.”

As we head into 2020, it will be interesting to see if these predictions come true and find out what next year has in store.

The post DevOps trends – what will stay in 2019 and what will make it to 2020? appeared first on DevOps Online North America.

But smaller doesn’t always mean less, as Chris Garvey, Executive Vice President of Products at 2nd Watch argues as he says, “The point of getting smaller is to allow your organization to think bigger by getting the most advantage out of cloud resources and bringing more value to your customers and users faster.”

Microservices and the cloud

Garvey further speaks of how microservices become more significant when it comes to running applications in the cloud. He says: “By breaking applications into smaller and smaller pieces, you can support agility, on-demand scale, and frequent updates. It’s much easier and less risky to change, update or move around little pieces of an application than to shift or change the entire application in bulk.”

Because of these tiny changes, users will be mostly unaware of when application updates are happening, meaning that changes can be made quickly and easily.

Not only does this bring benefit to the user and the developer, but Garvey speaks of how DevOps teams will also be able to manage applications through “highly efficient DevOps methodologies”

Is it all good?

However, despite the positives that microservices hold, the Executive Vice President points out that all of this doesn’t equal an all-round perfect system. He says: “Suddenly, you’ve got tiny bits of code that relate to just one small piece of functionality supporting a business process. There are times when development teams build too many microservices in an application, when simpler is better.”

He, therefore, suggests using a service mesh to deal with this issue. The service mesh acts as a ‘go-between’ or ‘connector’.

“This technology sits on the network and handles all the communications between microservices and facilitates access to shared services and tools such as service discovery, failure detection/recovery, load balancing, encryption, logging, monitoring, and authentication. This allows your development teams to focus their time and effort on the services themselves, rather than writing the code or logic to discover all the services and physically network to them. The service mesh handles all the connections,” says Garvey.

The other benefits of using service mesh to deal with problems are that it reduces developer effort so they don’t have to worry about the communications between containers.

What to think about

When considering a service mesh, Garvey says that it can come with difficulties, but that overall, it could have a major positive impact on a set-up. He adds: “Adding a service mesh to your infrastructure will add complexity in some ways, yet it will pay off in spades by decreasing management and maintenance needs overall as you transition to a heavy microservices and cloud-native application environment. Done thoughtfully, service mesh technology can enable better speed, performance, flexibility and economics for your applications.”

The post How using service mesh alongside microservices can be huge appeared first on DevOps Online North America.