DZone Spotlight

Source code is one of the most valuable assets for any company. So if it gets stolen or leaked, this can result in colossal damages to your business. Source code theft can cause financial and reputational losses in the long term perspective. Even the giants in the industry are at risk, as the source code of Windows 2000 was stolen from Microsoft in 2004, and a recent data breach cost Capital One around $300 million. That's why securing your source code and protecting it from theft should be one of your top priorities. Why Is Securing Source Code Important? Recently, attempts to compromise services, software, apps, and devices have risen as the rewards for hackers can be quite profitable. Source code includes a lot of valuable information since it plays a crucial role in creating and building software, application, extensions, web services, and so much more. Unfortunately, source code security doesn't get enough attention in many cases. By stealing your source code, hackers can get ahold of important and sensitive information such as technical specifications, passwords, OAuth tokens, encryption keys, users' personal data, and so on. Without proper security, they can easily copy, modify, or distribute this data. Besides that, hackers can use information from the source code to exploit vulnerabilities and cause data breaches. You could lose a lead in the development of innovational products to your opponents if stolen source code gets sold to competitors. How to Secure Source Code There are several ways to secure and protect your source code from theft. Creating a dedicated policy, encryption, and securing endpoint devices are just some of the precautions you should implement. Also, it is best to use a layered approach instead of point protection when using technologies to mitigate source code theft. Implement Source Code Security Policy The policy should include rules and requirements to protect source code during the development lifecycle. It should cover the source code development process and all employees involved in the development. Every regulation you want to implement has to be clearly outlined in the policy. This includes encryption and security protocols, application shielding and hardening process, use of repositories, and access controls. You should also add documentation, training, and recommendations on best secure coding practices. Manage Access Control Defining who has access to the source code is fundamental in securing it from theft. Usually, there is no need to give a developer access to the whole code. Global access to source code brings potential security risks, so always avoid giving it unless absolutely necessary. You should use the "least privilege model" rule when managing source code access control. In addition, you can define and isolate source code areas when giving access and use the Zero Trust model when possible. Using multifactor authentication will also prevent access to course codes from unauthorized users. Implement two-factor authentication to ensure that only users with appropriate privileges can obtain company data and source code. Secure Your Endpoint Devices Securing your entry point is a crucial step in protecting source code from theft. Endpoint devices such as laptops and desktops are prone to malware attacks and other malicious activities. You should use Data Loss Prevention tools should be used to prevent source code leaks and exfiltration. In addition, protecting your devices with anti-malware, VPN, and antivirus solutions such as Avast, Clario, and Norton brings an additional level of security. While endpoint security is important, you should also remember to secure all other devices. Any phone or tablet connected to the same network as the entry-point device can bring potential risks to the source code security. If someone accesses these devices, they can get ahold of passwords and other sensitive information to further attack your source code. Use special code to check if your phone is hacked, regularly check it for malware and install the latest updates to keep your device safe. Avoid Insecure Source Code Usage It is easy to miss some security flaws during the development process. Analysis and testing tools are a great way to check source code security. Static Application Security Testing software can scan your code for security flaws, vulnerabilities, violations of coding standards, and other development issues. The tool works in real-time, providing updated information on an early stage of the software development life cycle. You should also use Dynamic Application Security Testing to find vulnerabilities and flaws outside the code. The tool can find issues with third-party interfaces and prevent SQL injection, cross-site scripting, insecure server configuration, and other types of attacks. Protect Source Code With Patents and Copyright Copyright laws and patents can't prevent course code theft, but they can confirm the ownership of the code. Source code can include new concepts and technological inventions, so it should be protected as intellectual property. That is why securing the idea, and written code with patents and copyright is crucial to state your ownership in case of source code theft or legal dispute. Conclusion Securing source code and protecting it from theft is crucial for every business. Applying multiple security layers to your code hardens and bulletproofs your development against attacks. It can take one data breach to bring colossal financial and reputational damages to your business. So creating protection policies, managing access, and securing your endpoint devices are just some of the approaches you should take to protect your source code.

A loosely coupled architecture is a software application development model wherein multiple components are connected with one another but are not heavily dependent on each other. Together, these components create a general network or system, despite each service being an independent entity created to perform a single task. The primary purpose of a loosely coupled architecture is to create a system that doesn’t fail due to the failure of a single component. Service-oriented architectures (SOAs) normally comprise a loosely coupled architecture. Example of a Loosely Coupled Architecture Consider an instance wherein you have created two classes in a program: A and B. When a method of Class A calls the method of Class B or uses variable instances defined in Class B, both classes are tightly coupled. However, when Class A depends on the interface of Class B instead of the methods defined in Class B, both classes are loosely coupled. Above is an example of a food ordering app that uses a loosely coupled system. The app contains different services such as order service, restaurant service, delivery service, and customer service. When a customer orders a food item, the order service takes care of processing it. The restaurant service receives this data and prepares the food while the delivery service handles the delivery part. Customer service assists customers when need be. In this case, each individual service is not heavily dependent on any of the other services. All services communicate via APIs in order to send and receive the required information. Therefore, when one service crashes, it can be instantly replaced without disturbing the other components of the app. Similarly, the order service can be automatically scaled during peak hours or seasons. Loosely Coupled Architecture vs. Tightly Coupled Architecture Loosely coupled vs. tightly coupled architecture is an important point to ponder. In the software development world, coupling refers to the dependency of an object on another. The degree of knowledge an object has about another or the level of dependency of one object on another determines whether the system is loosely coupled or tightly coupled. When the dependency level is low, we say it’s loosely coupled. Basically, this means one object knows what the other objects expose through an API. Similarly, two systems are loosely coupled when changes to one system don’t force a change in the other. Each service in a loosely coupled system is designed with a single purpose or responsibility and can be independently deployed, managed, scaled, and removed. Each service contains an interface (REST API) for communication. Seeing as each service can use a different programming language, platform, technology, and framework, it’s easy to make changes to individual services, perform tests, scale services and remove them without affecting the system. The loosely coupled architecture accommodates extensive APIs and interoperable resource schemas decoupled from the interface. On the other hand, objects in a tightly coupled architecture heavily depend on the other components of the system. Each object must collaborate and coordinate with other objects or components in order to complete a function. In this case, the logic of one class is called by another. This means one object or class requires another object or class to complete a task. Therefore, each class takes on multiple responsibilities, a change made to one class also forces a change in one or more other classes. The Importance of Microservices in a Loosely Coupled Architecture Microservices is an architectural design that facilitates the development of an application as small and independent services that run their own processes and communicate using lightweight protocols and messaging systems, making them platform-agnostic and language-agnostic. Each service is independent, testable, highly maintainable, independently deployable, and implements a business capability. Most importantly, each service is maintained, deployed, created, and owned by a small team. Microservices is a notable variant of a service-oriented architecture that leverages the loosely coupled architecture approach. In fact, loose coupling is the key component of microservices architecture. Microservices architecture is highly important to create a loosely coupled system, as the coupling is inevitable in a software system design. For instance, in an e-commerce portal, the order service should communicate with the customer service or delivery service using APIs. That said, microservices allow you to keep this coupling as minimal as possible. Microservices comprise a set of collaborating services that work together using different coupling methods. Runtime Coupling: The degree to which the availability of one service impacts the availability of another service. Design-time Coupling: The degree to which a change in a service triggers a change in another service. Infrastructure Coupling: The degree to which one service’s resource consumption impacts another service’s resource consumption. Each coupling method brings its own challenges to the table. For instance, runtime coupling reduces availability when a change occurs. As such, you’ll experience a long queue of calls in a microservices architecture. When you implement design-time coupling, a small change in an API requires all the services that interact with that API to be changed. Therefore, all of the teams involved with those services must collaborate and discuss the change. As such, it’s important to keep design-time coupling as loose as possible, especially when different collaborating teams are involved. Microservices make it easy to implement loose coupling in a design-time coupling model while enabling you to efficiently handle coupling challenges using lean development and DevOps CI/CD best practices. Which AWS Services Can Be Used for Loosely Coupled Architectures? Amazon Simple Queuing Service (SQS) and Simple Notification Service (SNS) are powerful mechanisms that can help you build highly scalable and loosely coupled architectures, with coupling at the platform, network, and operation levels. Amazon Simple Queuing Service (SQS): When a client makes an order, the app that receives that order sends it as a message to the SQS. The message is queued and consumed by a function such as AWS Lambda. Once the message is processed, it’s automatically deleted. Amazon Simple Notification Service (SNS): Works as a “publish-subscribe” model wherein the application sends order messages to an SNS topic which is then replicated across various endpoints in order to run processes in parallel. AWS Lambda: Serverless compute engine. AWS Fargate: Container as a Service for serverless computing. AWS AutoScaling: Autoscaling service. Amazon S3: Storage service. Amazon API Gateway: API management service. AWS CloudWatch: Used to manage messages in SQS. Loosely Coupled Architecture Scenarios Unlike tightly coupled architecture which runs thousands of parallel processes or cores that are dependent on one another to perform a calculation, loosely coupled architecture runs smaller jobs in large numbers on a single node with parallelization occurring within the node. As processes are not highly dependent on each other, losing one node doesn’t affect overall functionality. The job is either processed later or deleted. It’s important to consider the following aspects when choosing a loosely coupled architecture. Compute: The underlying EC2 instance type should be determined based on the memory-to-compute ratio of an application. Network: Bandwidth and latency issues are not a concern in a loosely coupled scenario, as processes that run in parallel don’t need to interact much. Storage: Each loosely coupled app comes with a different storage requirement. Therefore, consider the dataset size and data transfer requirements. Deployment: Seeing as loosely coupled apps run on cores installed in different availability zones, they can be efficiently deployed using AWS ParallelCluster or AWS Batch. AWS Serverless Scenario With Loosely Coupled Architecture Serverless computing is a cloud-native software development approach that helps organizations easily and seamlessly build and run applications without the burdens of provisioning and managing servers. Servers are still used but are managed by the cloud vendor. The catch here is that the charge is not based on the number of servers or the bandwidth but rather on usage. It enables organizations to purchase back-end servers on a pay-as-you-go basis and only pay for the services used. Serverless computing comes in two models: 1. Function as a Service: A service that allows you to run code based on events without the complexities of infrastructure management. Applications run in a stateless mode wherein the server and client are loosely coupled and hence are independent, flexible, scalable, and fault-tolerant. Regarding compute engines, AWS Lambda is a popular serverless FaaS tool from AWS. For container-based workloads, AWS Fargate is available. For event triggering, we recommend using Amazon SQS, AWS SNS, and Eventbridge. 2. Backend-as-a-Service: The task of running the server-side logic is outsourced to a cloud vendor. AWS BaaS tools include Amazon Elasticsearch Service for logging, AWS Kinesis for analytics, and AWS Cognito for IAM. There are three types of serverless invocation methods: Synchronous Invocation: Used when a client request requires an immediate response. Asynchronous Invocation: Used when you don’t want the client to wait for a response and instead alert the client through a notification once the process is completed. Steaming Invocation: Used to upstream, process, and downstream data at the same pace. When it comes to serverless computing, loosely coupled architecture with an asynchronous method is a good choice. That said, don’t forget to ensure it is fail-fast and fans out properly. Conclusion Software technologies rapidly change, forcing organizations to adapt to newer technologies and trends continually. When it comes to loosely coupled vs. tightly coupled architecture, information flow and coordination between services are better in a tightly coupled architecture. However, they constrain you regarding flexibility when making changes to your apps on the go. A loosely coupled architecture is the need of the hour. Not only does it allow you to swap or scale components instantly, but it also helps you add new features without affecting the availability and performance of the existing system. With microservices, lean development, and DevOps practices, a loosely coupled architecture allows you to stay in the competition or even ahead.

Today with new technologies emerging to serve customers, efficient delivery of the software and the ability to quickly resolve the issues that may occur are among the keys to a successful product launch. The users demand quality and seamlessly working products, and businesses want to deliver the software faster. Testing is one of the necessary procedures to ensure that the software is performing as entitled and, thus, doesn’t contain bugs. There are various approaches to executing the testing, which may depend on many factors. But as practice shows, the more often you test your product, the less time it takes to release and less budget to fix the mistakes. The most efficient is to implement continuous testing into your software development lifecycle. It means executing automated tests whenever changes are made to the code. Continuous testing is performed throughout the product’s lifecycle and is part of the CI/CD pipeline. It makes the SDLC timeline faster and accelerates the DevOps processes. In my previous article, I explained one of the most booming SDLC types — The v model. The cycle moves from Development to Testing to Deployment. It differs from traditional testing, in which development and quality assurance stages while the software is handed from one team to another. Continuous testing and the DevOps process shorten the time of receiving developers’ feedback on the problems and their further fixing. Automated testing is more effective than manual when it comes to repetitive tasks. Continuous Testing in DevOps DevOps combines software development and IT operations to make the development lifecycle faster and enable continuous delivery, ensuring the high quality of the software. Developers and IT operators work together in cooperation, not separated from one another. They perform as one team, and engineers are engaged in every stage of the product lifecycle and possess multidisciplinary skill sets. Collecting feedback at each stage, such as project design, coding, testing, deployment, and maintenance, can lead to ineffective use of resources, long integration cycles, and delays in product updates. Continuous testing ensures receiving feedback early by automatizing manual testing and reducing the possibility of human mistakes. It works in coordination with continuous integration, validating new code integrations. Pre-defined QA scripts are automatically utilized at every stage when the new code is integrated into the product. It doesn’t involve any specific person to make tests manually. It allows immediate source code validation, providing feedback to the teams. The test usually starts with integration testing and continues with system testing, regression testing, and user acceptance testing. If the test fails, the development team can fix the bug before it influences the work of other teams in the different stages of the development lifecycle after the revised code goes to the testing cycle again. If the test runs successfully, the software automatically goes to the next cycle stage, usually continuous delivery, thus ensuring a sustainable delivery model. Types of Continuous Testing There are several types of continuous testing to ensure the flawless performance of your product on different levels. They are: Unit tests test the individual methods, functions, components, and modules. These low-level tests are easy to automate and quickly executed through a continuous integration server. Integration tests test your software’s units, modules, or components for compatibility. Typically there are several developers that code different software modules. This test helps to find defects in those modules while they are integrated. API tests validate Application Programming Interfaces to ensure API reliability, functionality, performance, and security. APIs communicate between two different software systems, and the API test ensures that the interaction is performed as expected. It is the middle layer between the database and the UI. This test doesn’t focus on the interface of the product or how it feels but on the software architecture organization logic. System tests are the process of testing the whole integrated software to verify that it meets the requirements. It is a composition of different tests to ensure that the computer-based system works appropriately, consisting of pieces of software. End-to-end system specifications are being examined through system testing. Tools to Automate Continuous Tests Automation is an essential part of the continuous testing process. Different tools allow quality assurance and developers to reach perfect quality and shorten the testing time, but not all of them may correspond to the requirements of your project. The right automation tool should perform all the assigned tests for your product, and in case even one fails, the tool must never be used. The automating tool should enable continuous release and deployment and cut cost and time of maintenance, making the code reusable and providing significant investment returns. There are several types of automation testing tools. They are open-source, commercial, and custom frameworks. Open source is a free platform that enables users to modify the source code to suit their testing needs. Commercial automation tools are available by subscription and provide more features and customer service throughout the testing process. The custom framework is usually developed by a team, as existing solutions do not meet the project’s requirements. The reasons for this may be the difference in testing environments or processes. To choose the right tool for your project, you should understand the requirements of your project, whether your team possesses the necessary skills, your budget, script maintenance difficulty and reusability, and integration capabilities. Benefits of Continuous Testing in DevOps Whenever changes to the code are made or new pieces are added, there is always a place for mistakes. While the software is being tested from the early stages of development, Continuous Testing ensures that error-free code is integrated into the software. It reduces the costs and time of the developments, as fixing bugs in the late stages is always more complex and pricey. Continuous testing with the help of test automation ensures that systems and subsystems work consistently. It creates a seamless flow of integrations with the use of Continuous Integration. It makes the environment robust and supports the configurations for comparative tests. Automation ensures comprehensive Test Coverage, covers all potential mistakes, and maintains every feature. It helps to ensure testing quality and create tests covering missing or not validated areas. Continuous testing also ensures more connection between the team of developers and testers. The rapid feedback on the mistakes evolves the work of the development teams, as finding a bug at the right time can help them avoid bottlenecks in future work. Test automation tools ensure reporting and make the development process more straightforward. The team remains on the same page regarding errors, failed tests, and those which succeeded. Continuous Integration and Version Control System create the merge request when the test passes successfully. It drastically decreases the time for Code Review.

Machine learning has smoothly weaved into our daily lives, and we do not even realize it. From asking Google for directions to using Siri, we have slowly become entirely dependent on machine learning. So what exactly is machine learning? In simple terms, it is a subfield of artificial intelligence that is made to learn and adopt the capability of machines to imitate intelligent human behavior by using certain algorithms and statistics to make inferences. Many apps are circulating the market currently that have made the lives of humans extremely easy. If you go looking, any mobile app developer who is an expert in the field can provide you with the service accordingly. But can you develop a machine learning app? It may be a bit difficult, but it is not impossible. Here is a guide that can help you understand machine learning app developments: Know the Problem While this may be the most obvious step in the machine learning app development process, it is often missed. Artificial intelligence has quite some hype in the digital world today. It is easy to get swept up in all the rage that artificial intelligence is creating. But it is crucial here to think about the logic behind the development of machine learning apps. Think about the needs and specifications of your target audience and whether you will create convenience for them with the machine app development or not. Ask yourself: Is it absolutely important for my business to make this machine-learning app? Can we forego ML and go for anything else? How can we add value for our customers with this? If any of the questions yield relevant answers, then you should opt for machine learning app development. Here, your main focus should be providing a good feature for your customers that they can facilitate from. You should also consider the machine learning guides provided by Google, Apple, and Microsoft. The below-mentioned questions are important to ask How can we warrant a successful result for the customers? Does our ML have the potential to evolve gradually? Do we have any alternatives if our ML fails? Are we facilitating our customers to provide feedback? Is our data enough to train a successful model? By answering all the above questions, you will be able to come to a reliable conclusion regarding your decision to use machine learning app development. You should be equipped with enough alternatives to ensure that you are not suddenly shocked if anything goes sideways. Hire the Right Professionals Machine learning is not just a task of a single person. It will take a team of competent professionals to showcase their skills and work expertly to build a machine-learning mobile application. In addition to application developers, you will also need designers, full-stack backend developers, QA engineers, data scientists, and analysts to ensure the smooth flow of the whole process. You will need special developers and analysts who specifically deal with data and create ML apps and models. Determine the Structure of the Application Before the advent of ML, developers always had to choose an external server for enabling AI features in different applications as needed. The main objective here is the presence of a robust ML infrastructure that can run different data analyses combined with an app that retrieves important output from the server. Now, the integration of ML has become quite easy for you to use. You can effortlessly decide the position of ML in your app. This can be according to your precise needs and what is feasible for you. Some of the options where you can keep your ML can be: Custom libraries On-device SDK Cloud hosting with APIs Hybrid approach Choosing the right place from the options mentioned above can be hard. The easiest option here is to keep the ML within the app that you built. It is safe and can be integrated simply. Choose a Premade Template for Machine Learning App Development When you plan on machine learning app development, you have two options here. Either build from scratch or choose a template off the shelf and start from there. Here, think about the possibilities you have if you develop ML from scratch. The development of machine learning from scratch will offer more flexibility. You can choose and pick any tech stack, feature, and AI tools that you want and include them. On the other hand, if you go for a template ML, they would take a lot of burden off your shoulders. Some specific features will already be available, and you will not need to go through the trouble of adding everything. The tech stack options include: AI/ML Stack: this includes a good amount of ML frameworks that allow you to expertly build different machine learning models. Some solutions are MXNet, TensorFlow, Keras, Caffe, etc Programming Language: the most common language for machine learning app development is Python. This language exceptionally works with any AI/ML library. This provides an ease to the users. The off-the-shelf options include: Mobile app hosting ML services: these are dominated by Google and Apple as they are the owners of Android and iOS, respectively. Cloud-hosting ML services: the notable names here are IBM, Google, Microsoft, etc. All these companies expertly use AutoML, taking full advantage of the service.

Books on bad programming habits take up a fraction of the shelf space dedicated to best practices. We know what good habits are – or we pay convincing lip service to them – but we lack the discipline to prevent falling into bad habits. Especially when writing test code, it is easy for good intentions to turn into bad habits, which will be the focus of this article. But first, let’s get the definitions right. An anti-pattern isn’t simply the absence of any structured approach, which would amount to no preparation, no plan, no automated tests and just hacking the shortest line from brainwave to source code. This chaotic approach is more like non-pattern programming. Anti-patterns are still patterns, just unproductive ones, according to the official definition. The approach must be structured and repeatable, even when it is counter-productive. Secondly, a more effective, documented, and proven solution to the same problem must be available. Many (in)famous anti-patterns consistently flout one or more good practices. Spaghetti code and the god object testify to someone’s ignorance or disdain of the principles of loose coupling and cohesion, respectively. Education can fix that. More dangerous, however, are the folks who never fell out of love with over-engineering since the day they read about the Gang of Four because doing too much of a good thing is the anti-pattern that rules them all. It’s much harder to fight because it doesn’t feel like you’re doing anything wrong. Drawn To Complexity Like Moths to a Flame – With Similar Results In the same as you can overdose on almost anything that is beneficial in small doses, you can overdo any programming best practice. I don’t know many universally great practices, only suitable and less suitable solutions to the programming challenge at hand. It always depends. Yet developers remain drawn to complexity like moths to a flame, with similar results. The usefulness of SOLID design principles has a sweet spot, after which it’s time to stop. It doesn’t follow an upward curve where more is always better. Extreme dedication to the single responsibility principle gives you an explosion of specialized boilerplate classes that do next to nothing, leaving you clueless as to how they work together. The open/closed principle makes sense if you’re maintaining a public API, but for a work-in-progress, it’s better to augment existing classes than create an overly complex inheritance tree. Dependency inversion? Of course, but you don’t need an interface if there will only ever be one private implementation, and you don’t always need Spring Boot to create an instance of it. The extreme fringes on opposite sides of the political spectrum have more in common with each other than they have with the reasonable middle. Likewise, no pattern at all gives you the same unreadable mess as well-intentioned over-engineering, only a lot quicker and cheaper. Cohesion gone mad gives you FizzBuzzEnterpriseEdition while too little of it gives you the god object. Let's turn over, then, to test code and the anti-patterns that can turn the efforts into an expensive sinkhole. Unclarity about the purpose of testing is already a massive anti-pattern before a single line of code is written. It’s expressed in the misguided notion that any testing is better than no testing. It isn’t. Playing foosball is better than ineffectual testing because the first is better for team morale and doesn’t lull you into a false sense of security. You must be clear on why you write tests in the first place. First Anti-Pattern: Unaware of the Why Well, the purpose of writing tests is to bring Sonar coverage up to 80%, isn’t it? I’m not being entirely sarcastic. Have you never inherited a large base of untested legacy that has been working fine for years but is languishing at an embarrassing 15% test coverage? Now suddenly the powers that be decide to tighten the quality metrics. You can’t deploy unless coverage is raised by 65 percentage points, so the team spends several iterations writing unit tests like mad. It’s a perverse incentive, but it happens all the time: catch-up testing. Here are three reasons that hopefully make more sense. First, tests should validate specifications. They verify what the code is supposed to do, which comes down to producing the output that the stakeholders asked for. A developer who isn’t clear on requirements can only write a test that confirms what the code already does, and only from inspecting the source code. Extremely uncritical developers will write a test confirming that two times four equals ten because that’s what the (buggy) code returns. This is what can happen when you rush to improve coverage on an inherited code base and don’t take the time to fully understand the what and why. Secondly, tests must facilitate clean coding; never obstruct it. Only clean code keeps maintenance costs down, gets new team members quickly up to speed, and mitigates the risk of introducing bugs. Developing a clean codebase is a highly iterative process where new insights lead to improvements. That means constant refactoring. As the software grows, it’s fine to change your mind about implementation details, but you can only improve code comfortably that way if you minimize the risk that your changes break existing functionality. Good unit tests warn you immediately when you introduce a regression, but not if they’re slow or incomplete. Thirdly, tests can serve as a source of documentation for the development team. No matter how clean your code, complex business logic is rarely self-explanatory if all you have is the code. Descriptive scenarios with meaningful data and illustrative assertions show the relevant input permutations much clearer than any wiki can. And they’re always up to date. Second Anti-Pattern: London School Orthodoxy I thank Vladimir Khorikov for pointing out the distinction between the London versus the classical unit test approach. I used to be a Londoner, but now I’m convinced that unit tests should primarily target public APIs. Only this way can you optimize the encapsulated innards without constantly having to update the tests. Test suites that get in the way of refactoring are often tightly coupled to implementation details. As long as you can get sufficient execution speed and coverage, I find no compelling reason for a rigid one-to-one mapping between source classes and corresponding test classes. Such an approach forces you to emulate every external dependency’s behavior with a mocking framework. This is expensive to set up and positively soul-crushing if the classes under test have very little salient business logic. A case in point: Java @RestController public class FriendsController { @AutoWired FriendService friendService; @AutoWired FriendMapper friendMapper; @GetMapping(“/api/v1/friends”) public List<FriendDto> getAll(){ return friendMapper.map(friendService.retrieveAll()); } } This common Controller/Service layered architecture makes perfect sense: cohesion and loose coupling are taken care of. The Controller maps the network requests, (de)serializes input/output, and handles authorization. It delegates to the Service layer, which is where all the exciting business logic normally takes place. CRUD operations are performed through an abstraction to the database layer, injected in the service layer. Not much seems to go on in this simple example, but that’s because the framework does the heavy lifting. If you leave Spring out of the equation, there is precious little to test, especially when you add advanced features like caching and repositories generated from interfaces. Boilerplates and configurations do not need unit tests. And yet I keep seeing things like this: Java @ExtendWith(MockitoExtension.class) public class FriendsControllerTest { @Mock FriendService friendService; @Mock FriendMapper friendMapper; @InjectMocks FriendController controller; @Test void retrieve_friends(){ //arrange var friendEntities = List.of(new Friend(“Jenny)); var friendDtos = List.of(new FriendDto(“Jenny”)); Mockito.doReturn(friendEntities).when(friendService).findAll(); Mockito.doReturn(friendDtos).when(friendMapper).map(eq(friendEntities)); //act var friends = controller.findAll(); //assert Assertions.assertThat(friends).hasSize(1); Assertions.assertThat(friends.get(0).getName()).isEqualTo(“Jenny”); } } A test like this fails on three counts: it’s too much concerned with implementation details to validate specifications and it’s too simplistic to have any documentary merit. And being tightly bound to the implementation, it surely does not facilitate refactoring. Even a “Hello, World!”-level example like this takes four lines of mock setup. Add more dependencies with multiple interactions and 90% of the code (and your time!) is taken up with tedious mocks setup. What matters most is that Spring is configured with the right settings. Only a component test that spins up the environment can verify that. If you include a test database, it can cover all three classes without any mocking, unless you need to connect to an independent service outside the component under test. Java @SpringBootTest @AutoConfigureMockMvc class FriendsControllerTest { @Test @WithAnonymousUser void get_friends(){ mockMvc.perform(get("/v1/api/friends")) .andExpect(content().string(“[{\“name\”: \”Jenny\”}]”)) } } Third Anti-Pattern: Trying to Test the Untestable The third anti-pattern I want to discuss rears its head when you try to write tests for complex business functionality without refactoring the source. Say we have a 1500-line monster class with one deceptively simple public method. Give it your outstanding debt, last year’s salary slips, and it tells you how much you’re worth. public int getMaxLoanAmountEuros(List<SalaryReport> last12SalarySlips, List<Debt> outstandingDebt); It’s different from the previous example in two important ways: The code-under-test centers on business logic and has high cyclomatic complexity, requiring many scenarios to cover all the relevant outcomes. The code is already there and testing is late to the party, meaning that by definition you can’t work in a test-driven approach. That of itself is an anti-pattern. We’re writing tests as an afterthought, only to validate what the code does. The code may be very clean, with all complexity delegated to multiple short private methods and sub-classes to keep things readable. Sorry, but if there are no unit tests, it’s more likely to be a big ball of mud. Either way, we can’t reduce the essential complexity of the business case. The only way to reach full coverage of all the code under this single public method is by inventing scenarios with different input (the salary and debt information). I have never been able to do that comfortably without serious refactoring, by delegating complex isolated portions to their own class and writing dedicated tests per class. If you’re terrified of breaking things, then changing the access level of private methods to default scope is safer. If the test is in the same package, you might write focused tests for these methods, but it’s a controversial strategy. Best avoid it. You’re breaking encapsulation, wading knee-deep in implementation details, which makes future refactoring even harder. You have to proceed carefully if you tamper with untested production code, but there is no good alternative other than a full rewrite. Writing thorough unit tests for messy code that you inherited without the privilege to refactor is painful and ineffectual. That’s because untested code is often too cumbersome to test. Such untestable code is by definition bad code, and we should not settle for bad code. The best way to avoid that situation is to be aware of the valid reasons why we test in the first place. You will then never write tests as an afterthought. Green Checkbox Addiction The productive path to establishing and maintaining effective test automation is not easy, but at least the good habits make more sense than the well-intentioned yet harmful anti-patterns I pointed out here. I leave you with a funny one, which you might call green checkbox addiction: the satisfaction of seeing an all-green suite, regardless of whether the tests make any sense. That's the false sense of security I mentioned earlier, which makes bad testing worse than no testing at all. It’s like the productivity geeks who create spurious tasks in their to-do lists for the dopamine spike they get when checking them off. Very human, and very unproductive.

Creating a full-fledged API requires resources, both time and money. You need to think about the model, the design, the REST principles, etc., without writing a single line of code. Most of the time, you don't know whether it's worth it: you'd like to offer a Minimum Viable Product and iterate from there. I want to show how you can achieve it without writing a single line of code. The Solution The main requirement of the solution is to use the PostgreSQL database. It's a well-established Open Source SQL database. Instead of writing our REST API, we use the PostgREST component: PostgREST is a standalone web server that turns your PostgreSQL database directly into a RESTful API. The structural constraints and permissions in the database determine the API endpoints and operations. -- PostgREST Let's apply it to a simple use case. Here's a product table that I want to expose via a CRUD API: Note that you can find the whole source code on GitHub to follow along. PostgREST's Getting Started guide is pretty complete and works out of the box. Yet, I didn't find any ready-made Docker image, so I created my own: Dockerfile FROM debian:bookworm-slim #1 ARG POSTGREST_VERSION=v10.1.1 #2 ARG POSTGREST_FILE=postgrest-$POSTGREST_VERSION-linux-static-x64.tar.xz #2 RUN mkdir postgrest WORKDIR postgrest ADD https://github.com/PostgREST/postgrest/releases/download/$POSTGREST_VERSION/$POSTGREST_FILE \ . #3 RUN apt-get update && \ apt-get install -y libpq-dev xz-utils && \ tar xvf $POSTGREST_FILE && \ rm $POSTGREST_FILE #4 Start from the latest Debian Parameterize the build Get the archive Install dependencies and unarchive The Docker image contains a postgrest executable in the /postgrest folder. We can "deploy" the architecture via Docker Compose: YAML version: "3" services: postgrest: build: ./postgrest #1 volumes: - ./postgrest/product.conf:/etc/product.conf:ro #2 ports: - "3000:3000" entrypoint: ["/postgrest/postgrest"] #3 command: ["/etc/product.conf"] #4 depends_on: - postgres postgres: image: postgres:15-alpine environment: POSTGRES_PASSWORD: "root" volumes: - ./postgres:/docker-entrypoint-initdb.d:ro #5 Build the above Dockerfile Share the configuration file Run the postgrest executable With the configuration file Initialize the schema, the permissions, and the data At this point, we can query the product table: Shell curl localhost:3000/product We immediately get the results: JSON [{"id":1,"name":"Stickers pack","description":"A pack of rad stickers to display on your laptop or wherever you feel like. Show your love for Apache APISIX","price":0.49,"hero":false}, {"id":2,"name":"Lapel pin","description":"With this \"Powered by Apache APISIX\" lapel pin, support your favorite API Gateway and let everybody know about it.","price":1.49,"hero":false}, {"id":3,"name":"Tee-Shirt","description":"The classic geek product! At a conference, at home, at work, this tee-shirt will be your best friend.","price":9.99,"hero":true}] That was a quick win! Improving the Solution Though the solution works, it has a lot of room for improvement. For example, the database user cannot change the data, but everybody can actually access it. It might not be a big issue for product-related data, but what about medical data? The PostgREST documentation is aware of it and explicitly advises using a reverse proxy: PostgREST is a fast way to construct a RESTful API. Its default behavior is great for scaffolding in development. When it’s time to go to production it works great too, as long as you take precautions. PostgREST is a small sharp tool that focuses on performing the API-to-database mapping. We rely on a reverse proxy like Nginx for additional safeguards. -- Hardening PostgREST Instead of Nginx, we would benefit from a full-fledged API Gateway: that enters Apache APISIX. We shall add it to our Docker Compose: YAML version: "3" services: apisix: image: apache/apisix:2.15.0-alpine #1 volumes: - ./apisix/config.yml:/usr/local/apisix/conf/config.yaml:ro ports: - "9080:9080" restart: always depends_on: - etcd - postgrest etcd: image: bitnami/etcd:3.5.2 #2 environment: ETCD_ENABLE_V2: "true" ALLOW_NONE_AUTHENTICATION: "yes" ETCD_ADVERTISE_CLIENT_URLS: "http://0.0.0.0:2397" ETCD_LISTEN_CLIENT_URLS: "http://0.0.0.0:2397" Use Apache APISIX APISIX stores its configuration in etcd We shall first configure Apache APISIX to proxy calls to postgrest: Shell curl http://apisix:9080/apisix/admin/upstreams/1 -H 'X-API-KEY: 123xyz' -X PUT -d ' #1-2 { "type": "roundrobin", "nodes": { "postgrest:3000": 1 #1-3 } }' curl http://apisix:9080/apisix/admin/routes/1 -H 'X-API-KEY: 123xyz' -X PUT -d ' #4 { "uri": "/*", "upstream_id": 1 }' Should be run in one of the Docker nodes, so use the Docker image's name. Alternatively, use localhost but be sure to expose the ports Create a reusable upstream Point to the PostgREST node Create a route to the created upstream We can now query the endpoint via APISIX: Shell curl localhost:9080/product It returns the same result as above. DDoS Protection We haven't added anything, but we're ready to start the work. Let's first protect our API from DDoS attacks. Apache APISIX is designed around a plugin architecture. To protect from DDoS, we shall use a plugin. We can set plugins on a specific route when it's created or on every route; in the latter case, it's a global rule. We want to protect every route by default, so we shall use one. Shell curl http://apisix:9080/apisix/admin/global_rules/1 -H 'X-API-KEY: 123xyz' -X PUT -d ' { "plugins": { "limit-count": { #1 "count": 1, #2 "time_window": 5, #2 "rejected_code": 429 #3 } } }' limit-count limits the number of calls in a time window Limit to 1 call per 5 seconds; it's for demo purposes Return 429 Too Many Requests; the default is 503 Now, if we execute too many requests, Apache APISIX protects the upstream: Shell curl localhost:9080/product HTML <html> <head><title>429 Too Many Requests</title></head> <body> <center><h1>429 Too Many Requests</h1></center> <hr><center>openresty</center> </body> </html> Per-Route Authorization PostgREST also offers an Open API endpoint at the root. We thus have two routes: / for the Open API spec and /product for the products. Suppose we want to disallow unauthorized people to access our data: Regular users can access products, while admin users can access both the Open API spec and products. APISIX offers several authentication methods. We will use the simplest one possible, key-auth. It relies on Consumer abstraction. key-auth requires a specific header: the plugin does a reverse lookup on the value and finds the consumer whose key corresponds. Here's how to create a consumer: Shell curl http://apisix:9080/apisix/admin/consumers -H 'X-API-KEY: 123xyz' -X PUT -d ' #1 { "username": "admin", #2 "plugins": { "key-auth": { "key": "admin" #3 } } }' Create a new consumer Consumer's name Consumer's key value We do the same with consumer user and key user. Now, we can create a dedicated route and configure it so that only requests from admin pass through: Shell curl http://apisix:9080/apisix/admin/routes -H 'X-API-KEY: 123xyz' -X POST -d ' #1 { "uri": "/", "upstream_id": 1, "plugins": { "key-auth": {}, #2 "consumer-restriction": { #2 "whitelist": [ "admin" ] #3 } } }' Create a new route Use the key-auth and consumer-restriction plugins Only admin-authenticated requests can call the route Let's try the following: Shell curl localhost:9080 It doesn't work as we are not authenticated via an API key header. JSON {"message":"Missing API key found in request"} Shell curl -H "apikey: user" localhost:9080 It doesn't work as we are authenticated as user, but the route is not authorized for user but for admin. JSON {"message":"The consumer_name is forbidden."} Shell curl -H "apikey: admin" localhost:9080 This time, it returns the Open API spec as expected. Monitoring A much-undervalued feature of any software system is monitoring. As soon as you deploy any component in production, you must monitor its health. Nowadays, many services are available to monitor. We will use Prometheus as it's Open Source, battle-proven, and widespread. To display the data, we will rely on Grafana for the same reasons. Let's add the components to the Docker Compose file: YAML version: "3" services: prometheus: image: prom/prometheus:v2.40.1 #1 volumes: - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml #2 depends_on: - apisix grafana: image: grafana/grafana:8.5.15 #3 volumes: - ./grafana/provisioning:/etc/grafana/provisioning #4 - ./grafana/dashboards:/var/lib/grafana/dashboards #4 - ./grafana/config/grafana.ini:/etc/grafana/grafana.ini #4-5 ports: - "3001:3001" depends_on: - prometheus Prometheus image Prometheus configuration to scrape Apache APISIX. See the full file here Grafana image Grafana configuration. Most of it comes from the configuration provided by APISIX. Change the default port from 3000 to 3001 to avoid conflict with the PostgREST service Once the monitoring infrastructure is in place, we only need to instruct APISIX to provide the data in a format that Prometheus expects. We can achieve it through configuration and a new global rule: YAML plugin_attr: prometheus: export_addr: ip: "0.0.0.0" #1 port: 9091 #2 Bind to any address Bind to port 9091. Prometheus metrics are available on http://apisix:9091/apisix/prometheus/metrics on the Docker network We can create the global rule: Shell curl http://apisix:9080/apisix/admin/global_rules/2 -H 'X-API-KEY: 123xyz' -X PUT -d ' { "plugins": { "prometheus": {} } }' Send a couple of queries and open the Grafana dashboard. It should look similar to this: Conclusion Creating a full-fledged REST(ful) API is a huge investment. One can quickly test a simple API by exposing one's database in a CRUD API via PostgREST. However, such an architecture is not fit for production usage. To fix it, you need to set a façade in front of PostgREST, a reverse proxy, or even better, an API Gateway. Apache APISIX offers a wide range of features, from authorization to monitoring. With it, you can quickly validate your API requirements at a low cost. The icing on the cake: when you've validated the requirements, you can keep the existing façade and replace PostgREST with your custom-developed API. The source code is available on GitHub. To go further: PostgREST Getting started with Apache APISIX Apache APISIX plugins

In this article, we will discuss testcontainers library and how to use it to simplify our life when it comes to integration testing our code. For the purpose of this example, I am going to use a simple application with its business centered around reviews for some courses. Basically, the app is a service that exposes some GraphQL endpoints for review creation, querying, and deletion from a PostgreSQL database via Spring Data R2DBC. The app is written in Kotlin using Spring Boot 2.7.3. I decided to write this article, especially for Spring Data R2DBC, as with Spring Data JPA, integration testing with testcontainers is straightforward. Still, when it comes to R2DBC, there are some challenges that need to be addressed. Review the App So let’s cut to the chase. Let’s examine our domain. Java @Table("reviews") data class Review( @Id var id: Int? = null, var text: String, var author: String, @Column("created_at") @CreatedDate var createdAt: LocalDateTime? = null, @LastModifiedDate @Column("last_modified_at") var lastModifiedAt: LocalDateTime? = null, @Column("course_id") var courseId: Int ) And here is its repository: Java @Repository interface ReviewRepository : R2dbcRepository<Review, Int> { @Query("select * from reviews r where date(r.created_at) = :date") fun findAllByCreatedAt(date: LocalDate): Flux<Review> fun findAllByAuthor(author: String): Flux<Review> fun findAllByCreatedAtBetween(startDateTime: LocalDateTime, endDateTime: LocalDateTime): Flux<Review> } And here are the connection properties: YAML spring: data: r2dbc: repositories: enabled: true r2dbc: url: r2dbc:postgresql://localhost:5436/reviews-db username: postgres password: 123456 When it comes to testing, Spring offers a fairly easy way to set up an in-memory H2 database for this purpose, but… There is always a but. H2 comes with some disadvantages: First, usually, H2 is not the production DB; in our case, we use PostgreSQL, and it is hard to maintain two DB schemas, one for production use and one for integration testing, especially if you depend on some provider features (queries, functions, constraints and so on). To have as much confidence as possible in tests, it is always advisable to replicate the production environment as much as possible, which is not the case with H2. Another disadvantage might be the possibility of production migration to another database – in this case, H2 having another schema won’t catch any issues, therefore, is unreliable. Others might argue that you can have separate testing dedicated DB on a server, machine, or even in a different schema. Still, again, the hassle of maintaining schemas and the possibility of collision with some other developer`s changes/migrations is way too big. Testcontainers to the Rescue Testcontainers is a Java library that supports JUnit tests, providing lightweight, throwaway instances of common databases, Selenium web browsers, or anything else that can run in a Docker container. With Testcontainers, all the disadvantages mentioned above are gone: because you are working with the production-like database, you don’t need to maintain two or more different separate schemas, you don’t need to worry about migration scenarios since you’ll have failing tests, and last, but not least you don’t need to worry about another server/VM’s maintenance since Testcontainers/Docker will take care of that. Here are the dependencies that we are going to use: Groovy testImplementation("org.testcontainers:testcontainers:1.17.3") testImplementation("org.testcontainers:postgresql:1.17.3") There are different ways of working with Testcontainers in Spring Boot. Still, I will show you the `singleton-instance pattern` (one database for all tests) since it is much faster to fire up on a database instance once and let all your tests communicate with it. For this to work, I am going to create an abstract class holding all the Testcontainers instances/start-up creation logic. Java @Tag("integration-test") abstract class AbstractTestcontainersIntegrationTest { companion object { private val postgres: PostgreSQLContainer<*> = PostgreSQLContainer(DockerImageName.parse("postgres:13.3")) .apply { this.withDatabaseName("testDb").withUsername("root").withPassword("123456") } @JvmStatic @DynamicPropertySource fun properties(registry: DynamicPropertyRegistry) { registry.add("spring.r2dbc.url", Companion::r2dbcUrl) registry.add("spring.r2dbc.username", postgres::getUsername) registry.add("spring.r2dbc.password", postgres::getPassword) } fun r2dbcUrl(): String { return "r2dbc:postgresql://${postgres.host}:${postgres.getMappedPort(PostgreSQLContainer.POSTGRESQL_PORT)}/${postgres.databaseName}" } @JvmStatic @BeforeAll internal fun setUp(): Unit { postgres.start() } } } Let’s take a close look at what we have here. Here we make use of testcontainers ability to pull Docker images and therefore instantiate or database container. Java private val postgres: PostgreSQLContainer<*> = PostgreSQLContainer(DockerImageName.parse("postgres:13.3")) Here we make sure to override our R2DBC connection properties in runtime with the ones pointing to our newly created container. Java @JvmStatic @DynamicPropertySource fun properties(registry: DynamicPropertyRegistry) { registry.add("spring.r2dbc.url", Companion::r2dbcUrl) registry.add("spring.r2dbc.username", postgres::getUsername) registry.add("spring.r2dbc.password", postgres::getPassword) } Since we are using Spring Data R2DBC, the spring.r2dbc.url needs a bit more care in order to be properly constructed as, at the moment, PostgreSQLContainer provides only the getJdbcUrl() method. Java fun r2dbcUrl(): String { return "r2dbc:postgresql://${postgres.host}:${postgres.getMappedPort(PostgreSQLContainer.POSTGRESQL_PORT)}/${postgres.databaseName}" } And here, we make sure to start our container before all of our tests. Java @JvmStatic @BeforeAll internal fun setUp(): Unit { postgres.start() } Having this in place, we are ready to write some tests. Java @DataR2dbcTest @Tag("integration") @AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE) class ReviewRepositoryIntegrationTest : AbstractTestcontainersIntegrationTest() { @Autowired lateinit var reviewRepository: ReviewRepository @Test fun findAllByAuthor() { StepVerifier.create(reviewRepository.findAllByAuthor("Anonymous")) .expectNextCount(3) .verifyComplete() } @Test fun findAllByCreatedAt() { StepVerifier.create(reviewRepository.findAllByCreatedAt(LocalDate.parse("2022-11-14"))) .expectNextCount(1) .verifyComplete() } @Test fun findAllByCreatedAtBetween() { StepVerifier.create( reviewRepository.findAllByCreatedAtBetween( LocalDateTime.parse("2022-11-14T00:08:54.266024"), LocalDateTime.parse("2022-11-17T00:08:56.902252") ) ) .expectNextCount(4) .verifyComplete() } } What do we have here: @DataR2dbcTest is a spring boot starter test slice annotation that can be used for an R2DBC test that focuses only on Data R2DBC components. @AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE) - here, we tell spring not to worry about configuring a test database since we are going to do it ourselves. And since we have an R2dbcRepository that delivers data in a reactive way via Flux/Mono, we use StepVerifier to create a verifiable script for our async Publisher sequences by expressing expectations about the events that will happen upon subscription. Cool, right? Let’s run it.io.r2dbc.postgresql.ExceptionFactory$PostgresqlBadGrammarException: [42P01] relation "reviews" does not exist Extensions in Action Bummer! We forgot to take care of our schema and data/records. But how do we do that? In Spring Data JPA, this is nicely taken care of by using the following: Properties files spring.sql.init.mode=always # Spring Boot >=v2.5.0 spring.datasource.initialization-mode=always # Spring Boot <v2.5.0 And by placing a schema.sql with DDLs and data.sql with DMLs in the src/main/resources folder, everything works automagically. Or if you have Flyway/Liquibase, there are other techniques to do it. And even more, Spring Data JPA has @Sql, which allows us to run various .sql files before a test method, which would have been sufficient for our case. But that’s not the case here, we are using Spring Data R2DBC, which at the moment doesn’t support these kinds of features, and we have no migration framework. So, the responsibility falls on our shoulders to write something similar to what Spring Data JPA offers that will be sufficient and customizable enough for easy integration test writing. Let’s try to replicate the @Sql annotation by creating a similar annotation @RunSql Java @Target(AnnotationTarget.FUNCTION) annotation class RunSql(val scripts: Array<String>) Now we need to extend our test’s functionality with the ability to read this annotation and run the provided scripts. How lucky of us that Spring already has something exactly for our case, and it is called BeforeTestExecutionCallback. Let’s read the documentation: BeforeTestExecutionCallback defines the API for Extensions that wish to provide additional behavior to tests immediately before an individual test is executed but after any user-defined setup methods (e.g., @BeforeEach methods) have been executed for that test. That sounds right; let’s extend it and override the beforeTestExecution method. Java class RunSqlExtension : BeforeTestExecutionCallback { override fun beforeTestExecution(extensionContext: ExtensionContext?) { val annotation = extensionContext?.testMethod?.map { it.getAnnotation(RunSql::class.java) }?.orElse(null) annotation?.let { val testInstance = extensionContext.testInstance .orElseThrow { RuntimeException("Test instance not found. ${javaClass.simpleName} is supposed to be used in junit 5 only!") } val connectionFactory = getConnectionFactory(testInstance) if (connectionFactory != null) it.scripts.forEach { script -> Mono.from(connectionFactory.create()) .flatMap<Any> { connection -> ScriptUtils.executeSqlScript(connection, ClassPathResource(script)) }.block() } } } private fun getConnectionFactory(testInstance: Any?): ConnectionFactory? { testInstance?.let { return it.javaClass.superclass.declaredFields .find { it.name.equals("connectionFactory") } .also { it?.isAccessible = true }?.get(it) as ConnectionFactory } return null } } Okay, so what we’ve done here: We take the current test method from the extension context and check for the @RunSql annotation. We take the current test instance – the instance of our running test. We pass the current test instance to getConnectionFactory , so it can take the @Autowired ConnectionFactory from our parent, in our case, the abstract class. AbstractTestcontainersIntegrationTest Using the obtained connectionFactory and ScriptUtils, we execute the scripts found on @RunSql annotation in a blocking-manner. As I mentioned, our AbstractTestcontainersIntegrationTest needs a tiny change; we need to add @Autowired lateinit var connectionFactory: ConnectionFactory so it can be picked by our extension. Having everything in place, it is a matter of using this extension with @ExtendWith(RunSqlExtension::class) and our new annotation @RunSql. Here’s how our test looks now. Java @DataR2dbcTest @Tag("integration") @ExtendWith(RunSqlExtension::class) @AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE) class ReviewRepositoryIntegrationTest : AbstractTestcontainersIntegrationTest() { @Autowired lateinit var reviewRepository: ReviewRepository @Test @RunSql(["schema.sql", "/data/reviews.sql"]) fun findAllByAuthor() { StepVerifier.create(reviewRepository.findAllByAuthor("Anonymous")) .expectNextCount(3) .verifyComplete() } @Test @RunSql(["schema.sql", "/data/reviews.sql"]) fun findAllByCreatedAt() { StepVerifier.create(reviewRepository.findAllByCreatedAt(LocalDate.parse("2022-11-14"))) .expectNextCount(1) .verifyComplete() } @Test @RunSql(["schema.sql", "/data/reviews.sql"]) fun findAllByCreatedAtBetween() { StepVerifier.create( reviewRepository.findAllByCreatedAtBetween( LocalDateTime.parse("2022-11-14T00:08:54.266024"), LocalDateTime.parse("2022-11-17T00:08:56.902252") ) ) .expectNextCount(4) .verifyComplete() } } And here is the content of schema.sql from resources. SQL create table if not exists reviews ( id integer generated by default as identity constraint pk_reviews primary key, text varchar(3000), author varchar(255), created_at timestamp, last_modified_at timestamp, course_id integer ); And here is the content of reviews.sql from resources/data. SQL truncate reviews cascade; INSERT INTO reviews (id, text, author, created_at, last_modified_at, course_id) VALUES (-1, 'Amazing, loved it!', 'Anonymous', '2022-11-14 00:08:54.266024', '2022-11-14 00:08:54.266024', 3); INSERT INTO reviews (id, text, author, created_at, last_modified_at, course_id) VALUES (-2, 'Great, loved it!', 'Anonymous', '2022-11-15 00:08:56.468410', '2022-11-15 00:08:56.468410', 3); INSERT INTO reviews (id, text, author, created_at, last_modified_at, course_id) VALUES (-3, 'Good, loved it!', 'Sponge Bob', '2022-11-16 00:08:56.711163', '2022-11-16 00:08:56.711163', 3); INSERT INTO reviews (id, text, author, created_at, last_modified_at, course_id) VALUES (-4, 'Nice, loved it!', 'Anonymous', '2022-11-17 00:08:56.902252', '2022-11-17 00:08:56.902252', 3); Please pay attention to create table if not exists from schema.sql and truncate reviews cascade from reviews.sql – this is to ensure a clean state of the database for each test. Now, if we run our tests, all is green. We can go ahead and do a little more to follow the DRY principle in regard to the annotations used on this test which can be collapsed under one annotation and then reused, like this. Java @DataR2dbcTest @Tag("integration-test") @Target(AnnotationTarget.CLASS) @ExtendWith(RunSqlExtension::class) @AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE) annotation class RepositoryIntegrationTest() And basically, that’s it, folks. With the common abstract class, test extension, and custom annotation in place, from now on, every new database integration test suite should be a piece of cake. Bonus But wait, why stop here? Having our setup, we can play around with component tests (broad integration tests), for example, to test our endpoints - starting with a simple HTTP call, surfing through all business layers and services all the way to the database layer. Here is an example of how you might wanna do it for GraphQL endpoints. Java @ActiveProfiles("integration-test") @AutoConfigureGraphQlTester @ExtendWith(RunSqlExtension::class) @SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT) @AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE) internal class ReviewGraphQLControllerComponentTest : AbstractTestcontainersIntegrationTest() { @Autowired private lateinit var graphQlTester: GraphQlTester @Test @RunSql(["schema.sql", "/data/reviews.sql"]) fun getReviewById() { graphQlTester.documentName("getReviewById") .variable("id", -1) .execute() .path("getReviewById") .entity(ReviewResponse::class.java) .isEqualTo(ReviewResponseFixture.of()) } @Test @RunSql(["schema.sql", "/data/reviews.sql"]) fun getAllReviews() { graphQlTester.documentName("getAllReviews") .execute() .path("getAllReviews") .entityList(ReviewResponse::class.java) .hasSize(4) .contains(ReviewResponseFixture.of()) } } And again, if you want to reuse all the annotations there, simply create a new one. Java @ActiveProfiles("integration-test") @AutoConfigureGraphQlTester @ExtendWith(RunSqlExtension::class) @SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT) @AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE) @Target(AnnotationTarget.CLASS) annotation class ComponentTest() You can find the code on GitHub. Happy coding and writing tests!

Congrats on nailing that interview! You’ve prepared hard and aced all the questions. You can relax now. “Do you have any questions for us?” says the interviewer . Oh! It's not over, you realize. You’re expected to have some questions. Interviewers are not trying to put you on the spot. Neither are they just being polite. The truth is that you are interviewing the company as much as the company is interviewing you. Asking questions at the end of the interview is how you know if they are a good fit for you. Are you interviewing for the job of your dreams or nightmares? Here are a few questions to find out. Questions to Ask the Recruiter The first person you’ll speak with is a recruiter (or someone from human resources), who may not know all the answers, but they can generally get them for you. At this point, the best thing to do is to get a feeling for how the company runs and what to expect next in the interview process. The Position 1. Why is the company hiring? A warming-up question to get a bit of context about the company's state. Is the position open because the company is growing, or are you filling in for someone who left? 2. What happened to the previous person in this position? Did they leave, or were they let go? If you’re filling in for someone who was let go, it may be a good idea to find out what happened. What were the circumstances of the previous employee’s exit? Tactfully learning about past devs can give you insights into what the company expects from you. 3. What is your turnover rate like? How many devs were hired last year, and how many resigned? What's the longest and shortest someone has been on the team? This is where we begin to hunt for flags. A high turnover rate suggests there’s something wrong with the working conditions at the company. You may not get a direct answer. But don't worry. You will have a chance to dig deeper into this issue in later interviews. 4. How does the onboarding process work? What are the next steps in the interview process? Get the information you need to prepare for the next steps. Life as an Employee 5. Does the company invest in employee development, training, or certifications? Is there a budget for learning activities or assisting conferences? It goes without saying that companies are interested in people with a drive to grow. At the very least, a company should give you enough time off to study or attend learning activities. They should get bonus points if they throw in financial aid for education. 6. Does the company allow remote work? How many days am I expected to be at the office? What’s the ratio of remote workers? Do you pay for relocation? The pandemic has pushed workers to remote positions. Some companies are 100% remote, while others offer a mix. What matters the most is if the team you're joining is hybrid or fully remote. With fully remote companies you can also ask if there are regular team building gatherings, hackathons, or celebrations. 7. Is there funding for co-working? Some people find it hard to concentrate when cooped up at home. For them, co-working is a good alternative when the office is too far away. 8. What is the parental leave policy? What is the policy on unpaid leave? What about paid time off like sick leave and vacation days? If these were not communicated in the job description, you should ask what the company’s policy on time off is. Questions to Ask After the Tech Interview At this point, you will probably find yourself talking to someone that can answer technical questions. These kinds of interviews can span various sessions, giving you the chance to talk to future colleagues, tech leads, or the CTO. Take this opportunity to learn about work-life balance and the prevalent workplace culture. A lot of these questions are aimed at exposing red flags. The Daily Loop 9. How many meetings should I expect in a typical week? Meetings are unavoidable, but some companies go overboard. We're trying to assess how much flow time we can expect to properly concentrate. 10. Do you practice CI/CD? What about trunk-based development? Terms like DevOps, Scrum, Lean, and Agile have been abused to the point that they have lost their meanings. Continuous integration (CI), on the other hand, has a more rigorous definition. So the question is: does the company practice it or not? Not practicing CI or trunk-based development is a pretty strong sign that the company relies on manual work to build and test their software. “But Tomas, of course, you would say that. You work for a CI/CD company, after all.” Yeah! But don't take just my word for it. The 2021’s edition of State of DevOps reaffirms the benefits of CI/CD coupled with trunk-based development: “Similar to our findings from previous years, we show that continuous testing is a strong predictor of successful continuous delivery. Elite performers who meet their reliability targets are 3.7 times more likely to leverage continuous testing... Elite performers who meet their reliability targets are 5.8 times more likely to leverage continuous integration... Continuous integration, as defined by Kent Beck and the Extreme Programming community, where it originated, also includes the practice of trunk-based development.” — State of DevOps 2021 Of course, there are places where CI/CD is not feasible. But 99% of the time it is the way to go. 11. How often do you deploy? How do you deploy? We’re starting to dig into the state of the CI/CD pipeline. The thing you want to hear is that they do continuous delivery several times per day, as it implies a fast cycle time. Unless you’re interviewing for a company in a regulated industry, manual and infrequent releases are red flags. They are signs of a slow and unproductive development cycle. 12. Do you practice TDD or BDD? How do you test code? Test-Driven Development and Behavior-Driven Development are disciplines that lead to higher productivity and better designs. Whether you’re in the test-driven camp or not, you should find out how the team tests and designs. One of the gravest red flags out there is a company that does no testing at all. 13. How do you track bugs/issues? What would you say is the ratio between features and fixes? We’re trying to discover the state of the technical debt. Technical debt results from prioritizing new features over fixing or refactoring existing code. Some debt is unavoidable, but accrue too much of it and there's a fair chance you’ll be in the unenviable position of extinguishing fires and triaging messy code. 14. What would you say is more important: don't touch a running system, fixing a bug or working on a new feature? What’s your approach to technical debt? Try asking directly about technical debt, but also see how serious they are about delivering customer value. 15. How well-rounded is the documentation? Do you have coding style guides? Do you have an executable test spec? Try to get a feel of the general state of documentation. Depending on the context, you can ask about API specs, design documents, style guides, user stories, and whatever documents support development. Insufficient documentation often means you’ll have to ask (and later on, be continually asked) for information in order to do your work. Tests such as contract and acceptance tests act as living documentation that validates that the code works according to spec and what has been agreed with the customer. Tools and Documentation 16. What version control system do you use? If the answer is “none,” it’s best to move on and try a different company. Unless you're being interviewed for a team lead or engineering manager position. In which case, ask if they're open to implementing. If they go for it, you're going to have your hands full for a few months at least and it's going to be a difficult road, so factor that into your benefits or salary negotiations. 17. What stacks/languages/frameworks are you using? Don’t worry if you’re not familiar with the technologies. You can learn any stack in a few weeks with good mentoring and dedication. 18. Can I use my ${favorite IDE}? We all have our favorite tools, don't we? 19. Is there company-provided equipment? Will I have root access to my machine? Can I bring my own devices? It might just be me, but I find not having admin access on my work machine disturbing. It shows that the company does not trust its employees. Developer Team Culture 20. Why did you choose to join this company? If you've built a rapport with the interviewer, ask a few personal questions. Knowing the values of the people you’re going to be working for or with is always valuable. 21. How big are the teams? What’s the ratio of juniors vs. seniors? We’re aiming to get insights into the team's composition and size. If you are interviewing for a junior position and the team is composed of a majority of seniors, that's excellent news. There’s nothing more stimulating than being surrounded by people more skilled than you. 22. How many women work for you? What is your process for making sure you have diversity in other ways? It might be a good opening question to discuss the diversity in the team. Tweak the question depending on the context. Refrain from using this question as a form of virtue signaling. A much better strategy is to focus on the facts: evidence shows that a more diverse group gets better solutions. I know diversity can be a charged subject, so try not to make judgments. Always keep the conversation unfailingly polite. 23. What's the biggest mistake you've made at this company? I like this question because it’s deeply related to the concept of generative culture. A generative culture is one where risk is shared, novelty is encouraged, and people are not excoriated for failures (they are used as learning opportunities instead). When people feel psychologically safe, they take more chances and experiment more, leading to innovation. On the opposite side of generative, we have pathological or bureaucratic cultures. In such conditions, people tend to “play it safe” — lest they be punished for failure. It goes without saying that this is not a rewarding environment to work in or one that will likely be good for you, professionally and mentally. Work-Life Balance 24. How many hours do people work in an average week? What time do people typically leave work? The basis of sustainable work without burning out is getting home early enough to have a life. Long work hours can mean the team is unproductive and compensates by overworking. 25. What’s the on-call schedule like? What are standard working hours and your expectations for overtime? How often will I be on call? How often are there emergencies or times when people have to work extra hours? This question complements the previous one. How much overtime happens in a typical month? Lots of overtime, habitual weekend work, and infrequent or manual deployment are signs of an unhealthy work-life balance. If the company shows all these red flags, keep shopping around. 26. Am I expected to be online on Slack/Teams the whole time, or can I batch my work? Much of my productive work is done while away from the keyboard. If you're like me, your best ideas come when walking or taking a shower. Having the chance to step out for a few minutes keeps us in a productive state. Questions to Ask the Manager, CEO, or Founder Once the technical interview torture sessions are over, you will likely get access to a manager, the CEO, or even one of the founders. These are great opportunities to show interest in the company while learning how the company is doing in the market. About the Company 27. Do you have a playbook? The playbook is the single source of truth for all the processes in the company. It describes how the company runs, ensuring that information is accessible to everyone. A playbook allows a new employee to quickly learn the ropes. 28. How do you make money? Are you profitable? How fast are you growing? If you're interviewing for a startup, keep in mind that it will take a few years to be profitable — if they make it at all. So, you’re basically making a high-risk, high-reward bet. Your professional growth will often map to the company’s. If you’re looking for stability and planning to stay for a few years, choosing an established company with a consistent cash flow is better. 29. What are the biggest challenges and opportunities the company or team faces now? Open-ended questions like this can give you a lot of insight into the company's goals and the mindset of management. Check if your professional goals align with those of the company. 30. Where do you see the company in the following 5/10 years? I find it one of the most challenging questions to answer. So, I think it’s only fair to return the favor. 31. How does the company set goals for the quarter/year? And what are they for this period? Shows interest in the company’s goals and, more importantly, will give you an idea of what the priorities will be during this quarter or year. Are they using OKRs (Objectives and Key Results)? What are those for this period? If not, what criteria do they use, and how do they measure their success? If there are no company or team goals, you’re either talking to the wrong person or with the wrong company. About the Position 32. What’s your definition of success for my role? What do you expect me to accomplish in the first 3 months? How will you evaluate my performance at the end of the trial period? How do you determine if someone is a poor fit for your company? It's only fair to know how your performance will be assessed after the trial period. 33. How do performance reviews work? How does the promotion process work? Are performance reviews tied to raises? You and your manager might have different definitions of success. Performance reviews align you, your manager, and the company. Scary as they can be, they facilitate the continuous improvement of people and the company. It is a moment for the manager to give feedback, recognize accomplishments, and provide guidance on career advancement. Without performance reviews, there is no feedback and very little chance of advancement or raises. 34. How much autonomy would I have to decide what to work on? How is work prioritized? Is there any allotted time for side projects/experimentation? We want to know who calls the shots. Take the chance to learn what the team is currently concentrating on. You might be lucky and find a company that allocates a fixed time to work on side projects and experimentation. Advancing your Career 35. Will there be regular 1-on-1s with my manager? You want these. 1-on-1s are enormously important to keep you and the manager on the same page. 36. Can I contribute to FOSS projects? Give talks? Are there any approvals needed? For those interested in contributing to open-source or giving talks while working at the company. These are valuable opportunities for professional growth. Conclusion Some companies will try to show their best side to attract good candidates. Push past the sales pitch and dig deeper. Choose questions that resonate with your interests and keep asking them until you're satisfied. Don't ask about things to which you should already know the answer. Check the job description, the company's website, and all the previous conversations to ensure you don’t sound like a broken record. The list combines questions from several sources (listed below) and my own experience. If you need more inspiration, check the following links: Questions I'm asking in interviews - Julia Evans Questions to ask your future web dev employer 105 Questions to Ask a Company During Your Tech Interview Reverse interview Best of luck, and thanks for reading!

This is an article from DZone's 2022 Performance and Site Reliability Trend Report.For more: Read the Report Software testing is straightforward — every input => known output. However, historically, a great deal of testing has been guesswork. We create user journeys, estimate load and think time, run tests, and compare the current result with the baseline. If we don't spot regressions, the build gets a thumbs up, and we move on. If there is a regression, back it goes. Most times, we already know the output even though it needs to be better defined — less ambiguous with clear boundaries of where a regression falls. Here is where machine learning (ML) systems and predictive analytics enter: to end ambiguity. After tests finish, performance engineers do more than look at the result averages and means; they will look at percentages. For example, 10 percent of the slowest requests are caused by a system bug that creates a condition that always impacts speed. We could manually correlate the properties available in the data; nevertheless, ML will link data properties quicker than you probably would. After determining the conditions that caused the 10 percent of bad requests, performance engineers can build test scenarios to reproduce the behavior. Running the test before and after the fix will assert that it's corrected. Figure 1: Overall confidence in performance metrics Source: Data from TechBeacon Performance With Machine Learning and Data Science Machine learning helps software development evolve, making technology sturdier and better to meet users' needs in different domains and industries. We can expose cause-effect patterns by feeding data from the pipeline and environments into deep learning algorithms. Predictive analytics algorithms, paired with performance engineering methodologies, allow more efficient and faster throughput, offering insight into how end users will use the software in the wild and helping you reduce the probability of defects reaching production. By identifying issues and their causes early, you can make course corrections early in the development lifecycle and prevent an impact on production. You can draw on predictive analytics to improve your application performance in the following ways. Identify root causes. You can focus on other areas needing attention using machine learning techniques to identify root causes for availability or performance problems. Predictive analytics can then analyze each cluster's various features, providing insights into the changes we need to make to reach the ideal performance and avoid bottlenecks. Monitor application health. Performing real-time application monitoring using machine-learning techniques allows organizations to catch and respond to degradation promptly. Most applications rely on multiple services to get the complete application's status; predictive analytics models will correlate and analyze the data when the application is healthy to identify whether incoming data is an outlier. Predict user load. We have relied on peak user traffic to size our infrastructure for the number of users accessing the application in the future. This approach has limitations as it does not consider changes or other unknown factors. Predictive analytics can help indicate the user load and better prepare to handle it, helping teams plan their infrastructure requirements and capacity utilization. Predict outages before it's too late. Predicting application downtime or outages before they happen helps to take preventive action. The predictive analytics model will follow the previous outage breadcrumbs and continue monitoring for similar circumstances to predict future failures. Stop looking at thresholds and start analyzing data. Observability and monitoring generate large amounts of data that can take up to several hundred megabytes a week. Even with modern analytic tools, you must know what you're looking for in advance. This leads to teams not looking directly at the data but instead setting thresholds as triggers for action. Even mature teams look for exceptions rather than diving into their data. To mitigate this, we integrate models with the available data sources. The models will then sift through the data and calculate the thresholds over time. Using this technique, where models are fed and aggregate historical data, provides thresholds based on seasonality rather than set by humans. Algorithm-set thresholds trigger fewer alerts; however, these are far more actionable and valuable. Analyze and correlate across datasets. Your data is mostly time series, making it easier to look at a single variable over time. Many trends come from the interactions of multiple measures. For example, response time may drop only when various transactions are made simultaneously with the same target. For a human, that's almost impossible, but properly trained algorithms will spot these correlations. The Importance of Data in Predictive Analytics "Big data" often refers to datasets that are, well, big, come in at a fast pace, and are highly variable in content. Their analysis requires specialized methods so that we can extract patterns and information from them. Recently, improvements in storage, processors, parallelization of processes, and algorithm design enabled the processing of large quantities of data in a reasonable time, allowing wider use of these methods. And to get meaningful results, you must ensure the data is consistent. For example, each project must use the same ranking system, so if one project uses 1 as critical and another uses 5 — like when people use DEFCON 5 when they mean DEFCON 1 — the values must be normalized before processing. Predictive algorithms are composed of the algorithm and the data it's fed, and software development generates immense amounts of data that, until recently, sat idle, waiting to be deleted. However, predictive analytics algorithms can process those files, for patterns we can't detect, to ask and answer questions based on that data, such as: Are we wasting time testing scenarios that aren't used? How do performance improvements correlate with user happiness? How long will it take to fix a specific defect? These questions and their answers are what predictive analytics is used for — to better understand what is likely to happen. The Algorithms The other main component in predictive analysis is the algorithm; you'll want to select or implement it carefully. Starting simple is vital as models tend to grow in complexity, becoming more sensitive to changes in the input data and distorting predictions. They can solve two categories of problems: classification and regression (see Figure 2). Classification is used to forecast the result of a set by classifying it into categories starting by trying to infer labels from the input data like "down" or "up." Regression is used to forecast the result of a set when the output variable is a set of real values. It will process input data to predict, for example, the amount of memory used, the lines of code written by a developer, etc. The most used prediction models are neural networks, decision trees, and linear and logistic regression. Figure 2: Classification vs. regression Neural Networks Neural networks learn by example and solve problems using historical and present data to forecast future values. Their architecture allows them to identify intricate relations lurking in the data in a way that replicates how our brain detects patterns. They contain many layers that accept data, compute predictions, and provide output as a single prediction. Decision Trees A decision tree is an analytics method that presents the results in a series of if/then choices to forecast specific options' potential risks and benefits. It can solve all classification problems and answer complex issues. As shown in Figure 3, decision trees resemble an upsidedown tree produced by algorithms identifying various ways of splitting data into branch-like segments that illustrate a future decision and help to identify the decision path. One branch in the tree might be users who abandoned the cart if it took more than three seconds to load. Below that one, another branch might indicate whether they identify as female. A "yes" answer would raise the risk as analytics show that females are more prone to impulse buys, and the delay creates a pause for pondering. Figure 3: Decision tree example Linear and Logistic Regression Regression is one of the most popular statistical methods. It is crucial when estimating numerical numbers, such as how many resources per service we will need to add during Black Friday. Many regression algorithms are designed to estimate the relationship among variables, finding key patterns in big and mixed datasets and how they relate. It ranges from simple linear regression models, which calculate a straight-line function that fits the data, to logistic regression, which calculates a curve (Figure 4). OVERVIEW OF LINEAR AND LOGISTIC REGRESSION Linear Regression Logistic Regression Used to define a value on a continuous range, such as the risk of user traffic peaks in the following months. It's a statistical method where the parameters are predicted based on older sets. It best suits binary classification: datasets where y = 0 or 1, where 1 represents the default class. Its name derives from its transformation function being a logistic function. It's expressed as y = a + bx, where x is an input set used to determine the output y. Coefficients a and b are used to quantify the relation between x and y, where a is the intercept and b is the slope of the line. It's expressed by the logistic function:where β0 is the intercept and β1 is the rate. It uses training data to calculate the coefficients, minimizing the error between the predicted and actual outcomes. The goal is to fit a line nearest to most points, reducing the distance or error between y and the line. It forms an S-shaped curve where a threshold is applied to transform the probability into a binary classification. Figure 4: Linear regression vs. logistic regression These are supervised learning methods, as the algorithm solves for a specific property. Unsupervised learning is used when you don't have a particular outcome in mind but want to identify possible patterns or trends. In this case, the model will analyze as many combinations of features as possible to find correlations from which humans can act. Figure 5: Supervised vs. unsupervised learning Shifting Left in Performance Engineering Using the previous algorithms to gauge consumer sentiment on products and applications makes performance engineering more consumer-centric. After all the information is collected, it must be stored and analyzed through appropriate tools and algorithms. This data can include error logs, test cases, test results, production incidents, application log files, project documentation, event logs, tracing, and more. We can then apply it to the data to get various insights to: Analyze defects in environments Estimate the impact on customer experience Identify issue patterns Create more accurate test scenarios, and much more This technique supports the shift-left approach in quality, allowing you to predict how long it will take to do performance testing, how many defects you are likely to identify, and how many defects might make it to production, achieving better coverage from performance tests and creating realistic user journeys. Issues such as usability, compatibility, performance, and security are prevented and corrected without impacting users. Here are some examples of information that will improve quality: Type of defect In what phase was the defect identified What the root cause of the defect is Whether the defect is reproducible Once you understand this, you can make changes and create tests to prevent similar issues sooner. Conclusion Software engineers have made hundreds and thousands of assumptions since the dawn of programming. But digital users are now more aware and have a lower tolerance for bugs and failures. Businesses are also competing to deliver a more engaging and flawless user experience through tailored services and complex software that is becoming more difficult to test. Today, everything needs to work seamlessly and support all popular browsers, mobile devices, and apps. A crash of even a few minutes can cause a loss of thousands or millions of dollars. To prevent issues, teams must incorporate observability solutions and user experience throughout the software lifecycle. Managing the quality and performance of complex systems requires more than simply executing test cases and running load tests. Trends help you tell if a situation is under control, getting better, or worsening — and how fast it improves or worsens. Machine learning techniques can help predict performance problems, allowing teams to course correct. To quote Benjamin Franklin, "An ounce of prevention is worth a pound of cure." This is an article from DZone's 2022 Performance and Site Reliability Trend Report.For more: Read the Report

Horizontal scaling, and, in particular, auto-scaling is a common challenge for many applications no matter their architectural approach (monolithic or microservices) and the deployment environment (cloud or on-premises). Today's cloud providers provide a rich variety of options and tools to accommodate this critical requirement, which is to be able to scale services instances up or down, based on specified rules, in an efficient manner in order to: Avoid unavailability Ensure the quality of service Optimize resources utilization Avoid unnecessary charges Many of the out-of-the-box solutions rely on Kubernetes and offer various levels of abstraction to make this process as smooth as possible. However, there are many cases where we don't really need or cannot afford all these cloud offerings as-a-service or we need to operate our own data center on-premises. As presented in a previous article "Look, Ma! No Pods!", HashiCorp Nomad is a simple and flexible deployment tool, able to manage both containers and non-containerized applications running on-prem, cloud, or hybrid environments. Lately, Nomad provides auto-scaling functionality via the Nomad Autoscaler Agent. As described in the Nomad Autoscaler Overview, the following strategies are supported: Horizontal Application Autoscaling: This is the process of automatically controlling the number of instances of an application to have sufficient work throughput to meet service-level agreements (SLA). Horizontal Cluster Autoscaling: The process of adding or removing Nomad clients from a cluster to ensure there is an appropriate amount of cluster resource for the scheduled applications Dynamic Application Sizing: Enterprise feature which enables organizations to optimize the resource consumption of applications using sizing recommendations from Nomad In this article, we will delve into a Horizontal Application Autoscaling use-case. More specifically we will: Spin up a minimal Nomad/Consul cluster on Google Cloud's Compute Engine VMs, using HashiCorp's IaC tool Terraform. Deploy via Nomad the following components: the Autoscaler Agent, an HAProxy Load Balancer, a Prometheus server, a Spring Native application, and a Redis standalone server which is used by the application as an in-memory data store. Generate some load against the Spring application in order to trigger the auto-scaling process and observe the overall system's behavior. Pre-Requisites In order to be able to run everything you need to: Create a new Google Cloud account or sign in to an existing one Create a new Google Cloud project (guide here) Download and install Google Cloud Command Line Interface (gcloud CLI) to your development machine Download and install HashiCorp Packer Download and install Terraform You then need to clone the following GitHub repositories: Terraform Google Nomad: contains the Terraform scripts used to provision the Nomad/Consul cluster on GCP. This is actually a fork from HashiCorp* with the following tweaks applied: Updated Ubuntu, Nomad, and Consul versions Additions to install Docker daemon on each provisioned VM Nomad configuration changes for enabling Telemetry and exporting metrics to Prometheus Minimal changes to Terraform .tf files to avoid errors with the latest versions of Terraform CLI Spring Boot Yaus contains the source code of the sample Spring Boot native app used for the demo, a Nomad job file for its deployment, and a JMeter Test Plan for the load testing *Side-note: The particular fork is selected due to familiarity with it at the time of writing. You are encouraged to also check the more recent nomad/terraform GitHub repo especially if you need to run the Nomad/Consul cluster localhost or use another Cloud Provider. Another alternative is to use the Caravan Open Source tool. Keep in mind that if you are interested in running the cluster on a local Windows machine using Vagrant, you need to disable the Hyper-V capability and this may cause side effects to your Docker Desktop. Spin Up a Nomad/Consul Co-Located Cluster Build a Google Image Open your gcloud CLI and authenticate to your account by executing: gcloud auth application-default login From within gcloud CLI, change the directory to the `terraform-google-nomad/examples/nomad-consul-image` folder. Then execute: packer build nomad-consul.json This will take some time and when the build finishes, it will output the name of a produced new Google Image, e.g., "nomad-consul-ubuntu18-2022-11-11-110511". This is actually an Ubuntu image, with Nomad & Consul client/server binaries plus Docker installed. Keep the image name at hand for the next step. Customize Terraform Input Variables From within gcloud CLI, go back to the `terraform-google-nomad` root directory and edit the variables.tf file in order to specify: The name of the GCP Project where all resources will be launched The GCP Region and Zone you wish the VMs to be provisioned The size of the Cluster (number of servers and clients) The machine type of the Compute Instance to run for each node type The namespace of the Nomad/Consul Server cluster The namespace of the Nomad client cluster The Google Image used to launch each node in the Nomad/Consul Server cluster The Google Image used to launch each node in the Nomad client cluster Use the same Google Image identifier for both nomad_consul_server_source_image and nomad_client_source_image. Based on the existing setup, Terraform configuration will take care of executing Nomad and Consul on either client or server mode automatically. Once you finish, save and exit the editor. Plan and Deploy the Infrastructure Now, from the same, root folder of the cloned project you may execute: terraform init And then you may run: terraform plan If the plan looks good, run: terraform apply Once the procedure finishes, you can have a look at the VM instances provisioned from your Google Cloud Console. It should look like the one below: Note that with the External IP of the nomad-server-* machine, you should be able to access Nomad and Consul admin UIs at HTTP://<nomad-server-external-ip>:4646 and HTTP://<nomad-server-external-ip>:8500 respectively. Terraform has taken care of all the internal and external network and firewall plumbing in order for the cluster to be functional and easily accessible, solely for testing purposes of course. Deploy Servers and Applications Now that we have our Nomad and Consul cluster up and running we can proceed with deploying Nomad Autoscaler Agent, Prometheus, HAProxy, and the sample microservice along with the Redis server it needs. Navigate to your Nomad admin UI, select "Run Job" and paste in the Job Definition area, the contents of the autoscaler.nomad job. Select "Plan" and if it looks OK, press "Run". Repeat the process for haproxy.nomad and prometheus.nomad. Notice that in our Nomad Job files we make use of the so-called template Stanza. This is a powerful method of generating configuration files on-the-fly, which are populated from environment variables, Consul Service discovery metadata, HashiCorp Vault secrets, etc. Let's see how this is useful, particularly with HAProxy's configuration. Check out the following excerpt from haproxy.nomad file: Plain Text backend http_back balance roundrobin server-template mywebapp 10 _demo-webapp._tcp.service.consul resolvers consul resolve-opts allow-dup-ip resolve-prefer ipv4 check With the above configuration, HAProxy will be able to discover dynamically via the Consul Service Registry, the instances (IPs and ports) of the application it will load balance. No need for a static or manually updated configuration, everything is referred to by service name! Cool, right? You may finish up the deployments by running redis.nomad and demo-webapp.nomad. By now, theoretically, you should have everything up and running, so we have an overview from the Nomad UI Jobs listing view: And the Consul UI Services listing view: Nomad Autoscaler Basics The following diagram depicts the Nomad Autoscaler architecture as initially described in HashiCorp Nomad Autoscaling Tech Preview, focusing on horizontal application scaling: For auto-scaling applications, Nomad provides a plugin interface through which we can connect multiple data stores for metrics. For example, if using Prometheus for monitoring, we can easily integrate it with the Prometheus plugin and define the scaling policies using the PromQL expressions. Let's have a look at the scaling Stanza, from the Spring microservice Nomad Job: JSON scaling { enabled = true min = 1 max = 4 policy { evaluation_interval = "2s" cooldown = "5s" check "cpu_usage" { source = "prometheus" query = "avg(nomad_client_allocs_cpu_total_percent{task='server'})" strategy "target-value" { target = 25 } } } } In simple words, we declare that we want Nomad to scale up to 4 instances of our app, if the average CPU load of the nodes running this task reaches 25%. There are many alternatives to try out, as long as there is a metric you are interested in, existing in Prometheus! Generate Load and Observe Time to generate some traffic using a sample JMeter Test Plan provided here. You need to open it with JMeter and modify the Server IP Address in the "HTTP Request" section: The Sample Spring Boot Native App The sample app is a simplified "URL Shortener" and exposes 2 endpoints that can be accessed via the HA_Proxy's External IP and port. The particular app is a Spring Boot native application built using Cloud Native Buildpacks in a Docker image. Spring Native provides support for compiling Spring applications to native executables using the GraalVM native-image compiler. Compared to the Java Virtual Machine, using native images provides key advantages, such as instant startup, instant peak performance, and reduced memory consumption. So, as far as auto-scaling is concerned we can surely benefit from all these advantages! The complete source code plus Nomad job files are available at the Spring Boot native app demo on GitHub (linked earlier in this post). Prometheus UI Once the traffic starts to spike and the CPU load increases, you can observe and confirm it from Prometheus UI: Nomad and Consul Observability At the same time, from the Nomad UI you can also tail the Nomad Autoscaler Agents LOGs: Confirm that Nomad begins to spin up more instances of the app, respecting our scaling policy. Look for lines like target=nomad-target from=1 to=2 reason="scaling up because the factor is XXX", target=nomad-target from=2 to=1 reason="scaling down because the factor is YYY", and possible errors or warnings that may be a sign that you need to apply a more sophisticated tuning. The additional instances are discovered dynamically by the HAProxy load balancer and start to take their share of the load. The number of service instances, their IPs, and ports are also visible in the Consul admin UI. Tearing It Down Once you stop the JMeter load test, eventually the application will scale down and remain with a single instance running. Finally, you may proceed to "destroy" the ephemeral GCP testbed, by executing from within your gcloud CLI the command: terraform destroy Closing Thoughts Horizontal scaling is a key characteristic of almost every solution; therefore, its architecture must be able to support it if and when needed. Auto-scaling is not always mandatory, especially if we are dealing with very predictable workloads. In this guide, we presented HashiCorp Nomad's way with a Spring Boot native microservice as the scaling target.