The dreaded part of every site reliability engineer’s (SRE) job eventually: capacity planning. You know, the dance between all the stakeholders when deploying your applications. Did engineering really simulate the right load and do we understand how the application scales? Did product managers accurately estimate the amount of usage? Did we make architectural decisions that will keep us from meeting our SLA goals? And then the question that everyone will have to answer eventually: how much is this going to cost? This forces SREs to assume the roles of engineer, accountant, and fortune teller.
The large cloud providers understood this a long time ago and so the term “cloud economics” was coined. Essentially this means: rent everything and only pay for what you need. I would say this message worked because we all love some cloud. It’s not a fad either. SREs can eliminate a lot of the downside when the initial infrastructure capacity discussion was maybe a little off. Being wrong is no longer devastating. Just add more of what you need and in the best cases, the services scale themselves — giving everyone a nice night’s sleep. All this without provisioning a server, which gave rise to the term “serverless.”

A Raspberry Pi is a mini-computer board to which you can connect a monitor, mouse, and keyboard, and install a Linux-based operating system with a GUI. Or you can use it in “headless” mode with no GUI and run, for example, a database server. There are many usages you can give a Raspberry Pi—from building a Minecraft server to smart mirrors, the possibilities are endless.
Since I started to discover MariaDB and learned about database clusters, Distributed SQL, and Xpand, the idea of building a Raspberry Pi cluster has been in the back of my head. A cluster like this is a great way to experiment with distributed systems.

In the video below, we take a closer look at DBCP connection pooling. Let’s get started!

In watching the 2022 EDA Summit presentation “Powering Your Real-Time, Event-Driven Enterprise with PubSub + Platform” by Shawn McAllister, CTO of Solace (sponsor of the Summit), I learned of the origins of his company. This article recounts his presentation with my personal synopsis. As he recounted, let’s “start with capital markets…where Solace started.”
Presentation Highlights and Additional Commentary
Shawn began by stating: “Capital markets became digital…over 20 years ago…They had, of course, on-prem applications…but the magic really happened in these ‘colocation centers,’ … data centers that are not owned by the bank or the buy-side firm… They’re shared, so they’re kind of like the clouds that you have today… and those colocation centers were then located close to the execution venues, where a lot of the trading happened.”

In my previous post, I discussed the difference between tests that target code versus those that target an API. A subset of the second category are automated tests for a web/mobile interface that mimic user behavior and validate the rendered responses, using Cucumber/Selenium, Cypress, or any other stack. These are typically written and executed as end-to-end tests, in that they require a production-like setup of the backend; but that needn’t be the case. GUI tests can turn into true component tests if they target the browser, but with a fully mocked backend. In a complex microservices architecture, it makes good sense to do so. In this article, I will highlight the motivation for writing those tests, and in a follow-up, I will give tips and examples on how to do so with the Karate framework. Feel free to dig into its excellent document if you can’t wait. 
Separation of Concerns Between Frontend and Backend
Traditionally, in the world of JSP and JSF, the backend of web applications would contain mostly display and rendering logic, on top of handling all business rules. With so much server-side rendering, you had no choice but to spin up the actual backend code if you wanted to automate a user scenario in the browser. Without the backend, nothing much would work. 

Tom Granot and I have had the privilege of Vlad Mihalcea’s online company for a while now. As a result,  we decided to do a workshop together talking about a lot of the things we learned in the process. This workshop would be pretty informal ad-hoc, just a bunch of guys chatting and showing off what we can do with tooling. 
In celebration of that, I thought I’d write about some of the tricks we discussed amongst ourselves in the past to give you a sense of what to expect when joining us for the workshop but also a useful tool in its own right.

As far as this modern and tech-oriented IT domain goes, DevOps has become a standard to judge operations’ overall efficiency and smoothness. However, like it is with everything in the world, there is still a sizeable chunk of enterprises in the process of either understanding what it means or completely not being aware of it at all.
In this post, we will try to cover a few crucial points that will include a brief overview of DevOps and why DevOps adoption might be helpful for businesses.

Functional and non-functional tests are the most popular approach to categorizing the different types of software testing. These two categories refer to the very essence of the testing process and what exactly is being tested. There are two things to know about functional and non-functional testing if you’ve never dug deep into these two testing categories before. 
One, the division between non-functional and functional testing is not set in stone, and for some testing types, categorizing them is no easy feat. Two, both functional and non-functional testing are essential for the success of your software testing project, albeit in different ways. Today, we will take a closer look at the difference between functional and non-functional requirements, where these two types of testing stand in the software testing process, and how they influence the cost of testing.

Regression testing verifies that system changes do not interfere with existing features or code structure. They are part of almost every test suite in software development lifecycles. It is common for developers to change or add a code section and unintentionally disrupt something that is working just fine.
Visual regression testing functions on the same logic but confines it to the visual aspects of the software. It works by comparing two images and automating complicated scenarios, like when we cannot identify the elements in the DOM tree. However, visual regression can be used on any website.

Introduction
There are four key capabilities necessary for a service or platform to be serverless:

No server management
Flexible scaling
High availability (fault tolerance)
No idle capacity

In this post, we will learn the basics of AWS Lambda and how you can use it for different use cases with ease. This will be an introduction post that can provide a foundation for upcoming demos and posts to help you learn AWS.