Microservices demand a new approach to QA. In contrast to monolithic applications, where every part of an application can be tested at the same time, microservices make QA much more complicated because each microservice may be developed and delivered according to its own schedule.
How can QA teams adapt to meet this challenge? Let’s take a look. […]
Read More →
As the application stack moves from hardware-centric to cloud-centric and now to container-centric infrastructure, much is changing. Processing power is on the rise with more powerful compute instances like GPUs becoming more accessible, and compute and data storage costs are on the decline as the cloud makes resources cheaper. The application stack is becoming more complex and dynamic. With all these changes, monitoring has become more important than ever. The only way to operate in a world of distributed apps, teams, infrastructure, and cloud tooling is to monitor the entire stack end-to-end.
Monitoring used to be limited to a single tool like Nagios. These tools monitored closed systems with components that don't change regularly, and with relatively few metrics to keep track of. Then came tools like New Relic which covered application performance. Slowly, as more tools were added to the mix, monitoring was taking on a best-of-breed approach. Integrations were becoming important as data is more valuable when viewed in different contexts and using multiple tools. And then Docker happened, and the world of software delivery has never been the same.
Let's look at the various types of monitoring tools required to gain visibility [...]
Read More →
Our Featured Guest Series is back! In this post, Phil Sturgeon warns about ripple effects that can take out entire applications, through making HTTP calls to unstable systems. Learn about using timeouts, retries, and circuit breakers to avoid this happening to you!
If you're interested in contributing to the Runscope blog, go to blog.runscope.com/writing for more information.
In a system-oriented architecture, it is crucial to communicate with other systems. In an ideal world each service knows enough information to satisfy its clients, but often there are unfortunate requirements for data to be fetched on the fly. Broker patterns, proxies, etc., or even just a remote procedure being triggered synchronously, like confirming an email has been sent successfully.
All of these things take time. Frontend applications (desktop, web, iOS, Android, etc.) talk to services, and services talk to other services. This chain of calls can stack up, as service A calls service B, unaware that system is calling service C and D… So long as A, B, C and D are functioning normally, the frontend application can hope to get a response from service A within a “reasonable time”, but if B, C or D are having a bad time, it can cause a domino effect that takes out a large chunk of your architecture, and the ripple effects result in a slow experience for the end users.
Slow applications can cost you a lot of money. A Kissmetrics survey suggests that every 1s slower a page loads, 7% fewer conversions will occur. This article explains how you can make your applications remain performant when upstream dependencies are not, using timeouts and retries. [...]
Read More →
A common requirement for Runscope users is to save and analyze test results for alerting, building custom dashboards, and other analytical purposes. One way to do that is to pipe all your test results to an Amazon S3 bucket. But what if you want more flexibility in how you store the test results? Or if you want to filter and process the test result data before storing it?
In this example, we will demonstrate how to call an Eventn microservice after each test completes and provide an example of saving the results to a database. We will also report on the data using SQL...
Read More →
Microservices are hot these days. According to Google Trends, searches for “microservices” were almost non-existent five years ago.
Maybe your team is one of the many now moving toward a microservices architecture. And with good reason: breaking a monolithic application into smaller, simpler services increases your project’s velocity, your ability to scale, and allows you to react more quickly to change.
In 2011, I was part of the Best Buy transformation that broke down the monolith of the website into separate web services. This is the story of that transition from monolith to microservices at one of the world’s biggest e-commerce platforms—what we learned, what worked, and how you can learn from our experience—while highlighting two keys in our transformation success: focusing on culture, and using Martin Fowler's Strangler Pattern.
But first: How did we get...
Read More →
This is the first post in our Featured Guest Series! Janet Wagner shares eight tips on how your company can ensure success when moving to a microservices architecture.
Microservices are all the rage these days, and you can find blog posts on most technology news sites and blogs about the topic. Major technology companies like Amazon and Netflix have been evangelizing microservices for quite some time now. The number of businesses building microservices architectures to power web and mobile applications is growing at a rapid pace and with good reason. There are significant benefits for companies running applications on microservices architectures such as high availability, high scalability of both the architecture itself and the engineering teams developing it, and ability to innovate and add new features faster.
If you are one of the many companies that have decided to venture into the world of microservices, there are a lot of things to consider. Do you start with a monolith or microservices architecture? How do you define the scope...
Read More →