Author: Rajiv Srivastava

Overview of Technical Debt

“Technical debt is a metaphor commonly used by software professionals in reference to short-term compromises made during the design, development, testing and deployment processes”.

In order to stay competitive, many organizations opt for software development methodologies like Agile, to accelerate the overall development processes. Cramped up release schedules often force teams to skip the standard practices, resulting in the accumulation of technical debt. Some technical debt is given less priority/importance during the rapid release cycles and is addressed post the production release. 

Organizations often push large, complex changes to speed up the release process. Short-term compromises are acceptable to a certain extent, however, long-term debt can damage an organization’s IT infrastructure and reputation. Sometimes, it comes with a heavy penalty of re-engineering and post-release fixes. These damages could be in the form of high costs for:

• Remediating pending technical debt
• Customer dissatisfaction due to scalability and performance issues 
• Increased hiring and training 
• Increased modernization time 

The cost of refactoring, re-engineering, re-base, and re-platform could be much higher than the original cost during initial development. These compromises should be thoroughly analyzed and approved by IT stakeholders and CXOs. This involves looking at future tradeoffs, risk appetite (risk capacity), and cost. Organizations also need to evaluate the pros and cons of taking technical debt decisions.

Taking on technical debt can be both tricky and risky for organizations. Hence organizations must factor in associated risks and operational costs. One of the consequences of Technical debt is the implied cost of reworking on applications and their architecture. Hence, organizations should choose easy development paths and limited solutions to shorten the production time.

If these technical debts are not addressed over time, the accrued interest makes it more challenging to implement changes, resulting in business and technical challenges.

A Scandinavian study reveals that developers waste, on average, 23% of their time due to technical debt.

As if that wasn’t alarming enough, Stripe published data that shows that software developers on an average spend 42% of their workweek dealing with technical debt and bad code

Major Drivers of Technical Debt 

• Faster solution design process
• Faster development of source code
• Quick releases
• Cut throat business competition to release new and unique features early in market

Impact of accumulating Technical Debt 

• It results in daily operational costs to accommodate remediation.
• A longer development cycle leads to slower application releases.
• It incurs long term financial loss due to technical debt accumulation.
• It may result in compliance issues and lack of proper standards.
• Code quality and design gets compromised.
• More time is spent on debugging rather than development.
• Failures that can put an organization’s reputation at risk.
• It can be a cause of security breaches and hefty fines.
• It can potentially lead to Loss of agility, lower productivity due to outages.

Types of Technical Debt

• Design/Architecture Debt: 

It represents a design work with backlogs which may include a lack of design thinking processes, UI bugs, and other design flaws that were neglected. Most organizations do follow standard design practices like The Open Group Architecture Framework(TOGAF) due to the agile way of designing. Tools and techniques like the ADM and TOGAF implementation governance, provide the required format and standard of solution design.

• Code Debt: 

It is the most common debt, which is skipped due to speedy agile delivery, complexity, or lack of subject knowledge. In some cases, new features are added in the latest version, which the dev team may not be aware of. This might result in the dev team working on the same feature again, resulting in unnecessary cost and time investment. Sometimes, the development team doesn’t follow standard best practices for coding or use quick workarounds or they do not refactor code because of time-bound release cycles.

• NFR/Infrastructure Debt

Introduced during designing and implementing Non Functional Requirements (NFR) such as:

• Inaccurate scalability configuration may crash applications on high load.
• Improper availability planning leads to outage issues when any data center is down.
• Inaccurate caching, logging leads to slower application performance.
• Repetitive code of error/exception handling may create refactoring and performance issues.
• Additional auditing and tracing may lead to performance issues and occupy unnecessary database storage.
• Ignorance of security may lead to serious data breaches and financial loss.
• Improper observability and monitoring may not give an alert on time for any major issues in application and infrastructure. 
• Testing Debt

The pressure of quick agile releases may force organizations to miss out on most of the manual and automated testing scenarios. Frequent unit and detailed end-to-end integration testing can detect major production issues. Sometimes, these detailed testings are skipped during the development phase which leads to major production bugs. 

• Process Debt

It is introduced when a few less important business and technical process flow steps are skipped. In agile development, there are many processes that are followed like sprint planning, Kanban, Scrum, retro meetings, and some other project management processes such as Capability Maturity Model(CMM) and Project Management Institute(PMI), etc. Sometimes these processes are not followed religiously due to time constraint pressure, which may have a severe impact later.

• Defect Debt

It is introduced when minor technical bugs are skipped during the testing phase like frontend UI cosmetic bugs, etc. These low severity bugs are deferred to the following releases, which may later have an impact in the form of production bugs. These production bugs spoil an organization’s reputation and profit margin.

• Documentation Debt

It is introduced when some of the less important technical contents in the document are skipped. Improper documentation always creates an issue for customers and developers to understand and operate after the release. The engineering team may not properly document the release and feature/fix details due to quick release schedules. As a result, users find it difficult to test and use new features. 

• Known or Deliberate  Debt

Known or deliberate debt is injected on purpose to accelerate releases. This acceleration is achieved by workarounds or alternate methods or technologies that use simple algorithms. For example, sometimes the dev team does not evaluate and consider better algorithms to avoid cyclomatic code complexity in the source code. As a result, it reduces the performance of the code.

• Unknown Outdated/Accidental Debt

It is introduced unknowingly by developers/designers and other stakeholders. It is sometimes introduced by regression of other related code changes, independent applications and libraries. For example, if all applications use the same error handling library code and if there is a regression issue in that error handling library, it may impact all dependent applications.

• Bit Rot Technical Debt

According to Wired, it involves, “a component or system slowly devolving into unnecessary complexity through lots of incremental changes, often exacerbated when worked upon by several people who might not fully understand the original design.” In practice, many old and new engineers work on the same module code without knowing the background details of the code. New engineers may rewrite or redesign code without understanding the initial design and background. It may create issues like regression issues, etc. This happens over time, and it should be avoided.

Causes of Technical Debt

• Business competition

Competitive business markets may force organizations to roll out frequent feature releases to better/surpass/overtake their competitors and keep the customers interested.

• Time constraints due to agile releases

With tighter deadlines, the development team doesn’t have enough time to follow all coding/design standards such as language-specific coding standards, TOGAF enterprise design, suitable design patterns, review, testing/validation, and other best development practices.   

• Save short-term cost

Some organizations want to develop and release features faster to save additional development costs on coding and design effort. They may prefer employing a small development team for faster releases with minimal short-term cost. These organizations may also hire junior or unskilled developers for more profit margin.  

• Lack of knowledge and  training

The development team may change very frequently during exit, internal movement, and new hiring. Faster release cycles may result in undertrained resources due to lack of functional or technical training and little to no knowledge transfers about product and design.

• Improper project planning

Tighter release schedules may result in improper project planning which plays a major role in introducing technical debt. For example, skipping important meetings with all business stakeholders or project planning phases such as agile retro, scrum, and sprint plan meetings, etc. 

• Complex technical design and technical solution

The development teams prefer simple technical design and solution over a complex one, because they don’t want to spend more time and effort understanding complex algorithms and technical solutions. Complex solutions take more time to understand and implement. They also need more POC evaluation and effort.

• Poor development practices

Most development teams prefer shortcuts by following poor development practices. Due to aggressive release timelines and lack of knowledge, dev teams don’t follow standard coding and design practices. 

• Insufficient testing

It is a major contributor to technical debt. Regular unit and integration testing for even a small code change are very important. Testing and validation are the only mechanisms to identify bugs and shortfalls in software applications. They also find technical and functional bugs. Insufficient testing can lead to the introduction of technical debt. 

• Delayed refactoring

Tight deadlines may force developments in giving less priority to refactoring code in the early stages. Hence they defer and delay code refactoring to prioritize quick releases

Due to high pressure, development teams defer and delay code refactoring to release software products early, or they don’t give priority to refactor code during initial development. Sometimes they backtrack, review and refactor with a delayed path with low priority. 

• Constant change

‘Change is the only constant.’ Software applications evolve and adopt new designs and technologies over time. It’s hard to cope with these constant changes in parallel. It takes time to revisit the source code, design and then implements the latest design and technologies.

• Outdated technology 

Most traditional organizations use outdated technologies. They make late decisions to upgrade or defer modernization with modern technologies. They miss a lot of new modern features which are considered to be technical debt. This debt can be mitigated only by shifting to modern technologies.  

• No involvement and mentoring by senior developer and architect

It’s very common to have less or no involvement of senior developers and architects during design and development. It’s very important to have senior mentors who can review and guide the development team to avoid technical debt. Those senior developers/architects might have a better understanding and experience of working on the same project or software applications.

Identifying and Analyzing Technical Debt

• User feedback

User feedback/reviews are very important in identifying technical debt and mitigating it. Organizations should listen and act on users’ feedback for improvement and handling bugs. These feedbacks and bugs are considered to be technical debt.

• Analyze bad code smell

Use manual and automated code review to understand bad code smell like memory leakage of JVM Java applications. There are many code analyzers or tools like SonarQube, PMD, FindBug, Checkstyle, etc, that can help. It could be integrated with automated build and deployment of CI/CD pipelines for every release. 

• Monitoring and observability tools

Application Performance Monitoring (APM) tools are the best tools to monitor software applications continuously, for example, VMware Wavefront/Tanzu observability, Dynatrace, DataDog, etc. They have special algorithms to check the performance of applications and underlying infrastructure. They also analyze application logs and generate failure reasons reports. These reports are a great source of identifying technical debt.

• Manual and automated code review 

Continuous, manual, and automated code review processes definitely help to identify technical debt using static and automated code analyzers.  

• Operational profit and loss analysis

It’s done through business and senior CxO people by analyzing operational cost (Opex) and loss analysis reports. These reports give a fair idea of improvement and address important technical debt quickly. Addressing this technical debt is very important for any organization because it impacts their business revenue. 

• Performance metrics

Application Performance Monitoring (APM) and load testing tools also generate performance reports of the software application on high load. This is the best way to identify and mitigate technical debt of Non-functional requirements (NFR) configurations like the performance of application and infrastructure, read caching availability, scalability, etc.

• Understand long-term or short-term requirement

Organizations identify technical debt by understanding long-term and short-term technical requirements. Accordingly, they prioritize, plan and remediate. These requirements are prioritized based on business criticality and urgency. 

• Review with latest industry-standard best practices

Some technical debt can be analyzed by comparing with the latest industry-standard software application design and development such as Agile, TDD, BDD, Scrum, Kanban, Cloud-native, microservices, micro frontends, TOGAF, and latest technology trends like Cloud, etc.

• Code refactoring tools and techniques

There are modern tools available that are capable of analyzing legacy monolithic apps and providing suggestions or refactoring partially to modern cloud-native microservices design. They also provide tools to migrate on-prem VM (Virtual Machine) to cloud VM with easy lift and shift rebase.

• Security analysis

Some security-related technical debt is identified during the security analysis phase. There are some security analysis tools available like CheckMarx, SonarQube which generate security reports for applications. There are many other infrastructure security tools like Vmware Carbon black endpoint in security, RSA, Aquasec, Claire aqua security etc.

Best Practices to Avoid Technical Debt

To reduce technical debt, it’s essential to analyze and measure it. You can calculate technical debt by using remediation and development costs as parameters. These are a few techniques to avoid technical debt:

• Listen to user feedback comments and remediate application technical debt.
• Religiously follow consistent code review practices. Have multiple rounds of manual code and design reviews by senior peers and architects.
• Do automated testing after every build and release.
• Monitor and analyze reports based on observability and monitoring tools.  
• Analyze and evaluate the performance and business impact of any new code and design change before implementing.
• Follow standard coding best practices.
• Follow the manual and automated static code review for any release.
• Use incident management and issue tracker to report and track bugs.
• Always review and validate solution architecture before implementation. 
• Follow static and dynamic code analysis using code analyzer tools like Somarqube, PMD, FindBug, etc.
• Follow agile iterative development approach and regularly do retrospective meetings. Also, measure technical debt/TDR in each iteration.
• Use project management tools like Jira, Trello, etc.
• Do code refactoring of legacy code. Always revisit code and modularize common code components.  
• Strictly follow test-driven development (TDD) and Behavioral Driven Development (BDD) approach for every module of code.
• Follow continuous build, integration, test, and validate the approach on all releases.
• Last but not the least, technical debt should be documented, measured, and prioritized. 

Estimating Technical Debt Cost

It’s very important to measure technical debt cost as it helps stakeholders and senior management to analyze and prioritize remediation costs. This should be a measurable number to make business decisions. It also helps to track the technical debt remediation status. There are so many measurable variables to measure code and constraints to calculate technical debt.

There are various tools available like SonarQube to check code quality, code complexities, lines of code, etc.

We can calculate technical debt as a ratio of the cost to fix a software system [Remediation Cost] to the cost of developing it [Development Cost]. This ratio is called the Technical Debt Ratio [TDR]:

Technical Debt Ratio (TDR) = (Remediation Cost / Development Cost) x 100%

Good TDR should be <=5%. High TDR shows bad code quality, which involves more remediation costs. 

Optionally, remediation cost (RC) and Development cost (DC) could be also replaced by hours, which will help to calculate remediation time in terms of total efforts in hours. 

Key Takeaways

These are some key points about technical debt cost:

• The average organization wastes 25% to 45% of its development cost.
• Hiring and training new engineers involve additional costs and an increase in coordination costs.
• Operational overhead cost by spending 15 to 20% on unplanned work.
• Impacts organizations’ revenue for additional and unplanned work.
• Waste of time in analyzing improvement of source code and design.
• Lower productivity rate around 60 to 70%.
• Cost of  project management and modern tooling.

Conclusion

Technical Debt can impact different factors like overall operations cost, velocity, quality of the product and can easily end up impacting teams’ productivity and morale. Hence avoiding technical debt or addressing it at the right intervals during the development process is the best way forward. We hope this blog helps you have a better understanding of Technical debt and best practices of their remediation.

Spring Cloud Gateway Overview

The Spring Cloud Gateway (SCG) is an API gateway proxy. It’s open-source based on the Java language. It has tons of features and can be embedded with code and can also be deployed as a separate service and scaled easily on Kubernetes containers.

The SCG is capable of handling client requests traffic by routing to desired microservices using the gateway handler mapping and aggregate responses of different back-end REST API endpoints of microservices.

SCG runs on Netty the non-blocking web server which provides asynchronous request processing for faster non-blocking processing of client requests.

It’s based on the following three major pillars:

• Route traffic to microservices: It handles routing client requests to designated REST API endpoint destinations. Imagine a use case where only the /catalogue API is being called. In this use case, the API gateway forwards client requests with payload to the Catalogue microservice. We will see this in our next source code example in the next section.
• Predicates: It helps to add the condition on incoming client requests like checking request URI, parameter, or assigning weight.
• Filters: It helps to implement the Spring framework web filters. Developers can modify the request and response based on the client’s preferences or security reasons. Developers can also add their custom filtering logic to filter incoming client requests and outgoing responses with no source code changes.

Spring Cloud Gateway Implementation Step by Step

In this section, we will implement the Spring Cloud Gateway routing features. In this coding exercise, we will cover major API gateway features route traffic, filters, and predicates.

We will use the dynamic routing configuration by making changes in application properties files. It will make changes applied dynamically without restarting microservices web apps. It will be deployed as a separate microservice on the Kubernetes container and can be deployed on multiple containers to provide HA

Prerequisite

These are basic installation requirements to build:

• Java 8+
• Spring Boot v2.4.1+
• Spring Cloud Gateway
• Java v8.x+
• Source code reference: https://github.com/rajivmca2004/spring-gateway-demo

Let’s create a simple Spring Boot Java microservice using the Spring Cloud Gateway:

1. Create the catalogue-cache-service project using the SprCreate the spring-gateway-demo project using the Spring Initializer web portal: https://start.spring.io/

2. Now, we will define Spring Cloud Gateway routes, predicates, and filters in the application.yaml file.

3. We will configure API gateway routing for two separate microservices customer-management-service and catalogue-service. We will test and verify these in the upcoming points.

1.	spring:  
2.	  application:  
3.	    name: catalogue-service  
4.	  jpa:  
5.	    hibernate:  
6.	      ddl-auto: update  
7.	  cache:  
8.	    type: redis  
9.	  redis:  
10.	    host: localhost  
11.	    port: 6379  
12.	  
13.	server:  
14.	  port : 8010  
15.	springdoc:  

4. We will use filters attributes [RS1] [RS2] of the Spring Cloud Gateway in the rate limiting implementation section in the same chapter:

---

1.	spring:  
2.	  application:  
3.	    name: spring-gateway-demo  
4.	  redis:  
5.	    host: localhost  
6.	    port: 6379      
7.	  cloud:  
8.	    gateway:  
9.	      routes:  
10.	      - id: catalogues_route  
11.	        uri: http://localhost:8010  
12.	        predicates:  
13.	        - Path=/catalogue  
14.	        - Weight=group1, 6  
15.	      - id: customers_route  
16.	        uri: http://localhost:8011  
17.	        predicates:  
18.	        - Path=/customers  

5. If the client goes to http://localhost:8080/customers, then it will route to the customer-management-service microservice REST API http://localhost:8011/customers which is running as a separate web service on a different container and port number:

6. If a client click to http://localhost:8080/catalogue, then it will route to the customer-management-service microservice REST API http://localhost:8010/catalogue which is running as a separate web service on a different container and port number:

Objective:

Design enterprise level system architecture to support email, SMS, Chat and other public social app integrations using API:

• Email
• SMS/OTP
• Push notifications (Mobile and Web browser)
• Chat – Whatsapp/Telegram

It’s a generic feature of all kind of web and mobile applications, which is required for all modern distributed applications regardless of using any programming languages and technologies. You can customize based on your business use cases.

I have tried to simplify this design concept to fulfil common use case requirements with high availability, high perfromance and analytical services. It’s a very important medium of communication with customers/users thru their desktop/mobile devices. I would recommend to implement using microservice architecture and deploy ion Kubernetes containers to make it fully cloud native modern system. Let’s get started!

Functional Requirement:

• Send notifications
• Prioritize notifications
• Send notifications based on customer’s saved preferences
• Single/simple and bulk notification messages
• Analytics use cases for various notifications
• Reporting of notification messages

Non-functional requirements (NFR):

• High perfromance
• Highly available (HA)
• Low latency
• Extendable/Pluggable design to add more clients, adapters and vendors.
• Support Android/iOS mobile and desktop/laptop web browsers.
• API integration with all notification modules and external integrations wth clients and service providers/vendors.
• Scalable for higher load on-prem (VMware Tanzu) and on public cloud services like AWS, GCP, or Azure etc.

System Design Architecture:

Note: Please click on the image to see clear view!

These are the solution design considerations and components:

1. Notification clients:

These clients will request for single and bulk messages using API calls. These clients will send notification messages to simple and bulk notification services:

• Bulk Notification clients: These clients send bulk notification(s).
• Simple Notification clients: These clients send single notification(s).

2. Notification Services:

These services are entry services which will expose REST APIs to clients and interact with the clients.  They are responsible to build notification messages by consuming Template Service. These messages will be also validated using Validation Service. 

• Simple Notification Service: This service will expose APIs to integrate client with backend services. It’s a main service, which will handle simple notification request.
• Bulk Notification Service: This service will expose APIs to integrate client with backend services. It’s a main service, which will handle bulk notification request.

This service will also manage notification messages. It wills persist sent messages to databases and maintain activity log. Same message can be resent using APIs of these services. It will provide APIs to add/update/delete and view old and new messages. It will also provide web dashboard which should have filter option to filter messages based on different criteria like date range, priority, module user, user groups etc.

3. Template Service:

This service manages all ready-to use templates for OTP, SMS, Email,chat and other push notification messages. It also provides REST APIs to create, update, delete and manage templates. It will also provide an UI dashboard page to check and manage message templates from web console.

4. User Selection Service:

This service will provide services to choose target users and various application modules. There could be use cases to send bulk messages to specific group of users or different application modules. It could be also AD/IAM/eDirectory/user database/ user groups based on customer’s preferences. Internally, it will consume API services of User Profile Service APIs and check customers notification preferences.

5. User Profile Service:

This service will provide various features including managing users profile and their preferences . It will also provide feature to unsubscribe for notifications and also notification receiving frequency etc. Notification Service will be dependent on this service.

6. Common Notification Service

• Scheduling Service:

This service will provide APIs to schedule notifications like immediate or any given time. It could be any of these followings:

• Second
• Minute
• Hourly
• Daily
• Weekly
• Monthly
• Yearly
• Custom frequency etc.

There could be other services also, which can be auto-triggered messages based on the scheduled times.

• Validation Service:

This service solely responsible for validating notification messages against business rules and expected format. Bulk messages should be approved by authorized system admin only.

• Validation Service:

It will also prioritize notification based on high, medium and low priorities. OTP notification messages have higher priority with a time-bound expiry time, they will always be sent in higher priority. Common Outbound Handler will consume messages and process and send based on the same priorities from reading in three different queues high, medium and low. Another use case of bulk messages can be send using low priority during off hours. Application notifications during transactions could be sent to medium priority like email etc. Business will decide priority based on criticality of the notifications.

7. Event Priority Queues (Event Hub):

It will provide event hub service which will consume messages from notification services in high, medium and low topics. It sends processed and validated messages to Notification Handler Service which internally uses Notification Preferences Service to check users personal preferences.

It will have these three topics, which will be used to consume/send messages based on business priority:

• High
• Medium
• Low

8. Common Outbound Handler:

This service will consume notification messages from Event Hub by polling event priority queues based on their priority. High precedence will be given to “High” queue and so on so forth. Finally It will send notification messages to message specific adapter thru Event Hub.

This service will also fetch target user/applications from User Selection Service.

9. Notification DB

It will persist all notification messages with their delivery time, status etc. It will have a cluster of databases with a leader which will be used to perform all write operations and read will be on read replica/followers. It should be No-SQL database.

10. Outbound Event Hub:

It finally transmits message to various supported adapters. These adapters will be based on different devices (desktop/mobile) and notification types( sms/OTP/Email/Chat/Push notifications).

11. Notification Adapters:

These are adapters which will transform incoming messages from event hub (Kafka) and send to external vendors according to their supported format. These are a few adapters, we can add more based on use case requirements:

• OTP Adapter Service
• SMS Adapter Service
• Email Adapter Service
• In-App Notification Adapter Service
• WhatsApp Chat Notification Adapter Service
• Telegram Notification Adapter Service

12. Notification Vendors:

These are the external SAAS (on cloud/on-prem) vendors, which provide actual notification transmission using their infrastructure and technologies. They maybe paid enterprise services like AWS SNS, MailChimp etc.

• SMS Vendor Integration Service
• Email Vendor Integration Service
• App Push Notification Vendor Integration Service
• WhatsApp Vendor Integration Service
• Telegram Vendor Integration Service

13. Notification Analytical Service

This service will do all analytics and identify notification usage, trends and do a reporting on top of that. It will pull all final notifications messages from analytical database (Cassandra) and Notification databases for analytics and reporting purpose.

These are a few use cases:

• Total number of notifications per day/per sec.
• Which is highly used notification system.
• What’s average size and frequency of messages.
• Filter out messages based on their priorities and many more…

14. Notification Tracker

This service will continuously read Event hub queues and track all sent notifications. It captures metadata of the notifications like transmission time delivery status, communication channel, message type etc.

15. Cassandra Database Cluster

This database cluster will persist all notifications for analytics and reporting purpose. It’s based on write more and read less concept.

This will provide good performance and low latency for high number of notifications, because it internally manages high number of write operations and sync up with other database nodes and keep duplicate data/messages for high availability and reliability. Messages will be always available in case of any node get crashed.

Please share feedback and let me know if you have any suggestion to make this design better!

15. Inbound Notification Service

This service will expose API endpoint to external clients and applications to send inbound messages.

16. INBOUND event Hub

This topic will be used to queue and process all incoming notification messages from Inbound notification clients.

17. Inbound Handler

This will consume all incoming notification messages from INBOUND topic.

18. Inbound Notification Clients

These inbound notification messages will come from internal and external sources/applications.

Disclaimer: It has been taken from my book – “Cloud Native Microservices using Spring and Kubernetes“.

Application Programming Interface (API) allows two apps/resources to talk to each other and is mostly referred for Service Oriented Architecture (SOA)

API is gaining more popularity when microservices development is booming for modern cloud-native applications or app modernization. We can’t imagine microservices without APIs, because there are so many distributed services in a microservice architecture, which can’t be easily integrated without the help of API. So, both Microservices and API compliments each other!

It’s an architectural design specification, a set of protocols that provides an interface to integrate and talk different microservices/monolithic apps and databases with each other. API does talk about how external services can communicate with apps, not how it works!

It creates an integration contract between different apps/external clients with a standard set of rules and specifications. It’s followed as a development practice for external clients/apps.

API is based on a contract first design pattern of development, where all developments happen around APIs specifications and protocols. Developers use the same standard practices across different microservices agile development teams.

API best practices

Now, we will discuss a few best API practices in detail:

• Follow OpenAPI standard: Modern apps API should follow OpenAPI specification to make it compatible and portable for all kinds of apps.
• API web dashboard support: It should be developer-friendly with the API management dashboard, which helps to create, manage, and monitor APIs in large systems or microservices environments. There are many API open source and enterprise solutions like OpenAPI based SwaggerHub, Google Apigee, and so on. They provide a web-based dashboard to manage APIs dynamically and can be exported  as source code and shared with development teams.
• Web-based HTTP with REST: Most of the apps, databases, and messaging systems use REST over HTTP protocol communication over the internet. REST is widely accepted, supported by most of the clients and logical integration apps, and so on. It’s more flexible, has rich features. If you are building an API then you should know the basics about HTTP web protocol and its methods, attributes, and status codes. Also, you should have a good understanding of the REST style of API interfaces, because REST is resource oriented architectural style.
• Return valid structured JSON response: Don’t return plain text message. It should be well-structured JSON, XML, or a similar response. Example is as follows:

{ 

“sku”: 101, 

“pInfo”: { 

“fullProductName”: “LG 50B6000FHD 127 Fridge”, 

“brand”: “LG”, 

“model”: “50B6000FHD”, 

“category”: “Fridge”, 

} 

}   

• Maintain status codes: API must return HTTP status codes because when a client sends a request to server through REST API, it expects response from the server, if it’s a success or failure. There are standard pre-defined error codes for this purpose:

• API Endpoint naming standard: Name the collections using plural nouns. The reason behind this, the same resource can return a single record or multiple records. It’s not recommended to have two separate resources URIs for these two resources. For example, /orders is a valid URI name for API, which serves both purposes.

Use nouns instead of verbs. It will be a standard naming convention, because multiple operations can be done on a single resource or object. For example, /orders is a noun and correct way because order can be created, updated, deleted, and fetched. It’s not recommended to use / createOrder, /updateOrder, /deleteOrder, and so on.

• Error handling, return error details with error code: Server resource should always returns appropriate error code, internal error code and simple human-readable error message for better error and exception handling at client-side apps, for example:

{ 

“status”: “400”, 

“erroCode”: “2200” 

“errorDetail”: “Connection refused” 

}

• Return appropriate HTTP response status code: Every REST endpoint should return a meaningful HTTP response code to handle server responses in a better way like:
  • 200 for success.
  • 404 for not found.
  • 201 resource is created.
  • 304 not modified. Response already in its cache.
  • 400 bad request. The client request was not processed, as the server could not understand what the client was asking for.
  • 401 unauthorized. Not allowed to access resources, and should re-request with the required credentials.
  • 403 forbidden. Client is authenticated, but the client is not allowed access to the page or resource for some reason.
  • 503 services unavailable. The server is down or unavailable to receive and process the request.
• Avoid nesting of related resources:  Sometimes, resources are related to each other like /orders resource object is related to catalogue category and user ID. We should not nest resources like: GET /orders/mobile/111 

It’s recommended to use top-level resource and make other related resources as a query parameter like this:

              GET /orders?ctg=mobile&userid=111

• Handle trailing slashes: It’s always advisable to use only one approach either with trailing spaces like /orders/ or without it /orders to avoid any confusion.
• Use sorting, filtering, querying, pagination: In many use cases, a simple resource name won’t work.
  • Sorting: You need to request server API resources to sort data in ascending or descending order: GET /orders?sort=asc
  • Filtering:  Filter on some business conditions like return product catalog responses based on price range: GET /orders?minprice=100&maxprice=500
  • Querying: Use cases where you want to query products based on their category like searching electronics products based on mobile category, for example: GET /orders?ctg=mobile&userid=111
  • Pagination: To improve performance and reduce latency on API calls over the internet, the client requests a subset of records at a single request like 10 records at a time for a given page. It’s called pagination: GET /orders?page=1&page_size=10

• Versioning: Versioning is a very important concept of API, which helps consumers to migrate to newer versions without any outage. In this scenario, some clients can access newer versions, and others can still use older versions. There are various ways of API versioning:
• Using URI path: It’s a standard technique to maintain different versions of the same APIs to support older versions of API resources, if the server-side API resource is upgraded to a newer version. Clients take some time to migrate and use the latest version of API. A new version to the same API resource can be changed, for example, /order/v1, / order/v2. The internal version of the API uses the 1.2.3 format like this: MAJOR.MINOR.PATCH.
  • Major version: It contains major code changes in business logic or other components. A new major version is added to the new API and the version number is used to route to the correct host.
  • Minor and patch versions: These are used internally for backwardcompatible updates. They are usually communicated in changelogs to inform clients about new functionality or a bug fix. The minor version represents minor changes and the patch contains break-fixes or security patches, and so on.
• Using query parameters: In this method, version number is added into query parameters in key and value. It’s simple to use, however not recommended because it’s difficult to route requests to APIs. For example: /orders?version=1.
• Using custom headers: In this method, version number can be added in HTTP request header. It avoids the clutter of URI versions; however, we need to create and manage new headers. For example: Accepts-version: 1.0.
• Using content negotiation: It’s also added in the header, allows a single resource representation instead of versioning the entire API which gives us more granular control over versioning. In this method, no need to create routing rules at the source API codes of different versions. This approach is not very popular, because it’s difficult to test and verify changes in browsers. For example: Accept: application/json; version=1
• Caching: API caching is a very much needed feature to improve API read (GET) performance. It caches responses from the API and for the same set of data and makes it available for other similar client requests. It’s recommended to use distributed caching techniques in a distributed microservices environment so that the same cached response should be available for multiple instances of the same microservice app.
• Rate limiting and throttling: Rate limiting is a technique of counting client requests with counter and limit based on the subscription or maximumallowed limit to control traffic on the server, also it is useful for security reasons to avoid hackers to hit continuously and bring the system down by consuming all the memory and compute resources.

API throttling controls the way API is being consumed by external apps/ or clients. It also indicates a temporary state and is used to control the data that external clients can access through a REST API. When a throttle is triggered, we can disconnect client requests, client apps, device ID, a user or just reduce the response rate. You can define a throttle at the application, API or user level.

There are multiple ways to implement rate-limiting. Spring Cloud Gateway provides rate limiting wrapper using distributed caching such as Redis or a similar caching tool.

• API gateway support: It’s recommended to expose APIs using API gateway tools to external apps. API gateway takes care of routing and orchestrating to designated server-side API, filtering, rate limiting, throttling, circuit breaker, API, authentication, authorization, and so on out of the box. It makes your API configuration outside of the business logic source code. It makes actual business logic code lighter and easy to debug and maintain.

Disclaimer: This blog content has been taken from my latest book:

“Cloud Native Microservices with Spring and Kubernetes”

On this Covid weekend. I have tried to consolidate a few popular cloud native and microservices related acronyms and buzzwords. Hope it will be helpful for a quick reference for novice and pro professionals :

• DDD: Domain Driven Design is used for microservices design based on closed context of independent business modules
• DoS: A Denial-of-Service (DoS) is a cyber-attack  to shut down a machine or network, making it inaccessible to its intended users. DoS attacks accomplish this by flooding the target with traffic, or sending it information that triggers a crash.
• DDoS: It’s an extension DoS. he incoming traffic flooding the victim originates from many different sources. This effectively makes it impossible to stop the attack simply by blocking a single source.
• API: Application Program Interface. It’s a computing interface which defines interactions between multiple software applications and can be interacted using REST.
• REST:  Representational state transfer (REST) is a software architectural style that defines a set of constraints to be used for creating Web services.
• OWASP: The Open Web Application Security Project (OWASP) is an online community that produces freely-available articles, methodologies, documentation, tools, and technologies in the field of web application security.
• DC: Data Center. It’s a physical facility that organizations use to host their critical applications and data.
• AZ: Availability Zones are isolated virtual locations within data center regions from which public cloud services originate and operate for HA, DR, backup.
• HA: High Availability
• DR: Disaster Recovery
• A&A: Authorization & Authentication
• BM : Bare Metal on plain OS.
• OS: Operating system
• SQL: Structured Query Language for RDBMS databases like MySQL, Oracle
• No-SQL: No- Structured Query Language for Non-RDBMS databases like document based database MongoDB, or column based database HBase, GreenPlum etc.
• BYO: Bring Your Own. Example: Bring your own software.
• DIY: Do It Yourself. It’s used for mainly self-service management/operations.
• TCP/IP: Transmission Control Protocol (TCP) and the Internet Protocol (IP). The Internet protocol suite is the conceptual model and set of communications protocols used in the Internet and similar computer networks. It works on handshaking dialogues.
• UDP: User Datagram Protocol (UDP) is one of the core members of the Internet protocol suit. It has no handshaking dialogues.
• DevOps: A set of practices that combines software development (Dev) and IT operations (Ops). It aims to shorten the systems development life cycle and provide continuous delivery and continuous integration with high software quality. DevOps is complementary with Agile software development.
• DevSecOps: is the philosophy of integrating security practices within the DevOps process. DevSecOps involves creating a ‘Security as Code’ culture with ongoing, flexible collaboration between release engineers and security teams.
• CI/CD: Continuous Delivery and Continuous Integration.
• Agile software development: Iterative sprint based rapid development model.
• H/W: Hardware
• H/W: Software
• CQRS: Command query responsibility segregation is microservice design pattern to separate read and write command responsibilities of data.
• SAGA: Microservices architectural pattern to implement a transaction that spans across multiple microservices
• HTTP: Hypertext Transfer Protocol (HTTP) is an application-layer protocol for transmitting web-content
• HTTPS: HTTP with SSL security
• SSL & TSL: Secure Sockets Layer and its successor, TLS (Transport Layer Security), are protocols for establishing authenticated and encrypted links between networked computers or cloud appications/services.
• Greenfield: New scratch application
• Brownfield: Legacy or old application
• MFA: Multi-factor authentication which involved more than one device to authenticate like login credentials with mobile based OTP confirmation.
• OTP: One Time password
• RBAC: Role-based access control (RBAC) is a method of restricting network access based on the roles of individual users within an enterprise.
• AWS: Amazon Web services. A leading public cloud provider.
• GCP: Google Cloud Platform. A leading public cloud provider

In this blog I will cover these following scope-

1. How to install TBS on local KIND/TKGI/TKG and other Kubernetes clusters.
2. How to auto build portable OCI docker image of a SpringBoot (Java) project using an automated build tool VMware Tanzu Build Service which auto detects Git source code repository commit and inject required dependencies and OS base image based on the source code languages and its configuration files. e.g: application.yaml and Maven’s pom.xml for Java/Spring app.
3. Push this docker image automatically to Docker Hub image registry. You can use any image registry like onprem Harbor, AWS ECR, GCR, Azure ACR etc.
4. Test Build Image by downloading from Docker-hub image registry and run using Docker
5. How to build Dot Net application using TBS (Appendix)
6. FAQ

Currently, Tanzu Build Service (TBS) ships with the following Buildpacks:

Why Tanzu Build Service( TBS)?

1. Save time to re-build, re-test and re-deploy during patching hundreds of containers.
2. It auto scans source code configuration and language and inject dependencies into docker image that will be required to compile and/or run the app on container/K8s.
3. Faster build and patching on hundreds of containers.
4. Faster developer productivity by setting local build on developer’s machine and sync with source code repo like GitHub etc.
5. Manage common project dependencies for dev teams and sync all developers code with single git branch to avoid any code conflict/sync issues.
6. Maintain latest image in image registry.
7. OCI docker image support, build and run anywhere!

Please refer this official documentation page for more detail

https://docs.pivotal.io/build-service/1-0/

Tanzu Build Service v1.0 GA can be installed on any Kubernetes private and public cloud clusters (v1.14 or later) including local machine using Kubernetes shipped with Docker Desktop, MiniKube and managed K8s like TKGI, TKG, GKE, and AKS clusters etc. 

Build Service Components Tanzu Build Service ships with the following components:

1. kpack
2. CNB lifecycle

Prerequisite:

1. Create Pivnet account. Refer to the official docs for more details on obtaining a Pivotal Network API token. You can create a free account and try on your local machine.
2. Install Pivnet CLI – https://github.com/pivotal-cf/pivnet-cli/releases/tag/v2.0.1
3. Install Docker Desktop (Mac, Windows) – Optional if you are trying to install on your local single node K8s cluster.
4. Docker Hub account
5. Install Kubernetes. I have used TKGI K8s cluster on GCP, you can also use KIND(K8s in Docker) with Docker Desktop.
6. Install the TKGI CLI or kubectl CLI
7. Install these three Carvel CLIs for your operating system. These can be found on their respective Tanzu Network pages:

• kapp is a deployment tool that allows users to manage Kubernetes resources in bulk.
• ytt is a templating tool that understands YAML structure.
• kbld is tool that builds, pushes, and relocates container images.

How to Install & Configure TBS:

You can download TBS from VMware Tanzu Network (formerly the Pivotal Network, or PivNet) or install using Pivnet CLI command.

Note: I have used Pivnet CLI for all the downloads from VMware PivNet. Refer this official installation guide and advance level configuration:

#Pivnet login using secret token
$ pivnet login --api-token='my-api-token'

$ pivnet download-product-files --product-slug='build-service' --release-version='1.0.2' --product-file-id=773503

#Unarchive the Build Service Bundle file:
$ tar xvf build-service-<version>.tar -C /tmp

#Login to docker-hub. This step will save docker-hub credentials to your K8s cluster. Note: You can use Harbor's url also.
$ docker login index.docker.io

#Login to VMware registry Docker-Hub thru Docker CLI (downloaded with Docker Desktop client)
$ docker login ≈

#Relocate the images for DockerHub with the Carvel tool kbld by running:
# Syntax: kbld relocate -f /tmp/images.lock --lock-output /tmp/images-relocated.lock --repository <IMAGE-REPOSITORY>

$kbld relocate -f /tmp/images.lock --lock-output /tmp/images-relocated.lock --repository itsrajivsrivastava/tanzu-build-service

Connect with your K8s cluster where you want to install TBS:

$ kubectl config use-context <K8s-cluster-name>

Now, install TBS on K8s. You can run these commands from home folder

Then use ytt to push the bundle to the image registry to DockerHub/image registry. It will upload all laungauge buildpacks and other supporting images to Docker-Hub/Harbor.

Note: It will take good time to upload bunch of images. If it fails then you need to re-run the command after deleting failed build of TBS. You can delete “kpack” and “build-service” Kubernetes namespaces.

$ ytt -f /tmp/values.yaml \
    -f /tmp/manifests/ \
    -v docker_repository="<IMAGE-REPOSITORY>" \
    -v docker_username="<REGISTRY-USERNAME>" \
    -v docker_password="<REGISTRY-PASSWORD>" \
    | kbld -f /tmp/images-relocated.lock -f- \
    | kapp deploy -a tanzu-build-service -f- -y

#Example:
ytt -f /tmp/values.yaml \
    -f /tmp/manifests/ \
    -v docker_repository=“itsrajivsrivastava” \
    -v docker_username="itsrajivsrivastava" \
    -v docker_password=‘******’ \
    | kbld -f /tmp/images-relocated.lock -f- \
    | kapp deploy -a tanzu-build-service -f- -y

Where:

• IMAGE-REPOSITORY is the image repository where Tanzu Build Service images exist.
• REGISTRY-USERNAME is the username you use to access the registry. gcr.io expects _json_key as the username when using JSON key file authentication.
• REGISTRY-PASSWORD is the password you use to access the registry

Install KP CLI:

kp CLI, is used for interacting with your Tanzu Build Service (TBS) installation on K8s cluster. Download the kp binary from the Tanzu Build Service page on Tanzu Network.

Import Tanzu Build Service Dependencies

The Tanzu Build Service Dependencies (Stacks, Buildpacks, Builders, etc.) are used to build applications and keep them patched.

1. Run this command on CLI  “docker login registry.pivotal.io” 
2. Accept all these EULA agreements online.

Note: Successfully performing a kp import command requires that your Tanzu Network account has access to the images specified in the Dependency Descriptor file. Currently, users can only access these images if they agree to the EULA for each dependency. Users must navigate to each of the dependency product pages in Tanzu Network and accept the EULA highlighted in yellow underneath the Releases dropdown.

Here are the links to each Tanzu Network page in which users must accept the EULA:

1. Tanzu Build Service Dependencies
2. Java Buildpack for VMware Tanzu
3. Java Native Image Buildpack for VMware Tanzu
4. Node.js Buildpack for VMware Tanzu
5. Go Buildpack for VMware Tanzu

Note: `kp import` will fail if it cannot access the images in all of the above Tanzu Network pages.

Note: You must be logged in locally to the registry used for `IMAGE-REGISTRY` during relocation and the Tanzu Network registry `registry.pivotal.io`.

These must be imported with the kp cli and the Dependency Descriptor (descriptor-<version>.yaml) file from the Tanzu Build Service Dependencies page:

$ kp import -f /tmp/descriptor-<version>.yaml

Verify kp Installation

List the custom cluster builders available in your installation:

You should see an output that looks as follows:

$  kp clusterbuilder list
NAME       READY    STACK                          IMAGE
base       true     io.buildpacks.stacks.bionic    itsrajivsrivastava/base@sha256:b3062df93d2da25aeff827605790c508570446e53daa8afe05ed2ab4157d1c02
default    true     io.buildpacks.stacks.bionic    itsrajivsrivastava/default@sha256:f16ed5de160ca9c13a0080d67280d0b2b843c926595c4d171568d75f96479247
full       true     io.buildpacks.stacks.bionic    itsrajivsrivastava/full@sha256:f16ed5de160ca9c13a0080d67280d0b2b843c926595c4d171568d75f96479247
tiny       true     io.paketo.stacks.tiny          itsrajivsrivastava/tiny@sha256:abc4879c03512a072623a7dcb18621d68122b5e608b452f411d8bc552386b8c5

# List the custom cluster builders available in your installation:

$ kp clusterstack list
NAME       READY    ID
base       True     io.buildpacks.stacks.bionic
default    True     io.buildpacks.stacks.bionic
full       True     io.buildpacks.stacks.bionic
tiny       True     io.paketo.stacks.tiny

Create Git and Image registry secrets in your K8s cluster:

# Docker Hub secret
$ kp secret create docker-creds --dockerhub itsrajivsrivastava -n tbs-demo
  dockerhub password:
  "docker-creds" created

# GitHub Secret
$ kp secret create github-creds --git https://github.com --git-user rajivmca2004 -n tbs-demo

#Verify and list secret
$ kp secret list -n tbs-demo

NAME                   TARGET
default-token-fqwvj
docker-creds           https://index.docker.io/v1/
github-creds           https://github.com

#Delete secret
$ kp secret delete <SECRET-NAME> -n tbs-demo

Create and manage docker image using kp CLI commands:

# Create TBS image: (--tag is mandatory)

$ kp image create <name> \
  --tag <tag> \
  [--builder <builder> or --cluster-builder <cluster-builder>] \
  --namespace <namespace> \
  --env <env> \
  --wait \
  --git <git-repo> \
  --git-revision <git-revision>

#Syntax:

$ kp image create spring-petclinic \
  --tag index.docker.io/itsrajivsrivastava/spring-petclinic:latest \
  --namespace tbs-demo \
  --git https://github.com/rajivmca2004/spring-petclinic \
  --git-revision master
"spring-petclinic" created

#  Verify image status
$ kp image status spring-petclinic -n tbs-demo
Status:         Ready
Message:        --
LatestImage:    index.docker.io/itsrajivsrivastava/spring-petclinic@sha256:4e712dec26810f026357281be4ba49ff8da3b45698700fd5dc470b7914c0d13d

Last Successful Build
Id:        1
Reason:    CONFIG

Last Failed Build
Id:        --
Reason:    --

# List the project(s):
  
$ kp image list -n tbs-demo
NAME                READY    LATEST IMAGE
spring-petclinic    True     index.docker.io/itsrajivsrivastava/spring-petclinic@sha256:d96fdd60633cd5582a9c28edceff80762ee79ef2985cd18f518bc1503563b7ef

# To check image list of any specific project 

$ kp image list spring-petclinic -n tbs-demo
NAME                READY    LATEST IMAGE
spring-petclinic    True     index.docker.io/itsrajivsrivastava/spring-petclinic@sha256:d96fdd60633cd5582a9c28edceff80762ee79ef2985cd18f518bc1503563b7ef

Build docker images:

Here, TBS will sync up with two systems:
1. GitHub – TBS will be in sync with GitHub repo for any commit and triggered after every commit. It also builds docker images.
2. Image Registry/Docker Hub – TBS will automatically push this image which has been created in the last step to image registry Docker-Hub and keep it refreshed all the time for developers and CI/CD build and deployment to K8s containers.
There are two ways to build the image:

1. Auto Build
2. Manual Build

Note: If you want to build source code directory which is inside sub-directories or if you have a parent project repo and multiple child project inside this

--sub-path DotNetBuild

#Example:
$ kp image create dotnetbuildtest index.docker.io/itsrajivsrivastava/dotnetbuildtest \
  --sub-path DotNetBuild \
  --namespace tbs-dotnet-demo \
  --git https://github.com/rajivmca2004/DotNetBuild.git \
  --git-revision master

1. Auto Build:

Note: First build will be triggered automatically when you create image at the first time.

To check auto build, just make some code changes in your Git branch and check the build progress using this command, It takes a few seconds to trigger. You can watch build logs locally –

# Use, this command, to check build status, also can be used for the first time to build. It will also show build revisions

$ kp build status spring-petclinic -n tbs-demo
Image:            index.docker.io/itsrajivsrivastava/spring-petclinic@sha256:e09bc84c0287d8d0985244876a68ae4b3963a96707622d81f6d9b9efa581be92
Status:           SUCCESS
Build Reasons:    COMMIT

Pod Name:    spring-petclinic-build-2-5csx8-build-pod

Builder:      itsrajivsrivastava/default@sha256:f16ed5de160ca9c13a0080d67280d0b2b843c926595c4d171568d75f96479247
Run Image:    index.docker.io/itsrajivsrivastava/run@sha256:ca460a285b00d8f25ca3734b8f783af240771eb10974d90e26501fd52c0271b8

Source:      GitUrl
Url:         https://github.com/rajivmca2004/spring-petclinic
Revision:    c5b4f7f717a1dc239c002c993c178f75283a7751

BUILDPACK ID                           BUILDPACK VERSION
paketo-buildpacks/bellsoft-liberica    4.0.0
paketo-buildpacks/maven                3.1.1
paketo-buildpacks/executable-jar       3.1.1
paketo-buildpacks/apache-tomcat        2.3.0
paketo-buildpacks/dist-zip             2.2.0
paketo-buildpacks/spring-boot          3.2.1

$ kp build list spring-petclinic -n tbs-demo

BUILD    STATUS     IMAGE                                                                                                                          STARTED                FINISHED               REASON
1        SUCCESS    index.docker.io/itsrajivsrivastava/spring-petclinic@sha256:b6d6a0944600be3552c0b33e0a0759a12b422168484ffff55f9f9e0be4c93217    2020-10-10 00:39:10    2020-10-10 00:59:40    CONFIG
2        SUCCESS    index.docker.io/itsrajivsrivastava/spring-petclinic@sha256:e09bc84c0287d8d0985244876a68ae4b3963a96707622d81f6d9b9efa581be92    2020-10-10 01:07:35    2020-10-10 01:09:48    COMMIT

2. Manual Build:

$ kp image trigger spring-petclinic -n tbs-demo

Check Build Logs:

# To view running logs for a build:

 $ kp build logs spring-petclinic -n tbs-demo

#Check logs for the given release:

 $ kp build logs spring-petclinic --build 1 -n tbs-demo

Note: First build will take some time to download all the dependent libraries. Subsequent build will be super fast!

Applied source code related build packages are mentioned in this following build logs. Since, its a Java app, these build-packs have been applied automatically –

[INFO] Building jar: /workspace/target/spring-petclinic-2.3.0.BUILD-SNAPSHOT.jar
[INFO]
[INFO] --- spring-boot-maven-plugin:2.3.0.RELEASE:repackage (repackage) @ spring-petclinic ---
[INFO] Replacing main artifact with repackaged archive
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  17:44 min
[INFO] Finished at: 2020-10-09T19:28:07Z
[INFO] ------------------------------------------------------------------------
  Removing source code

Paketo Executable JAR Buildpack 3.1.1
  https://github.com/paketo-buildpacks/executable-jar
  Process types:
    executable-jar: java org.springframework.boot.loader.JarLauncher
    task:           java org.springframework.boot.loader.JarLauncher
    web:            java org.springframework.boot.loader.JarLauncher

Paketo Spring Boot Buildpack 3.2.1
  https://github.com/paketo-buildpacks/spring-boot
  Launch Helper: Contributing to layer
    Creating /layers/paketo-buildpacks_spring-boot/helper/exec.d/spring-cloud-bindings
    Writing profile.d/helper
  Web Application Type: Contributing to layer
    Servlet web application detected
    Writing env.launch/BPL_JVM_THREAD_COUNT.default
  Spring Cloud Bindings 1.6.0: Contributing to layer
    Reusing cached download from buildpack
    Copying to /layers/paketo-buildpacks_spring-boot/spring-cloud-bindings
  Image labels:
    org.opencontainers.image.title
    org.opencontainers.image.version
    org.springframework.boot.spring-configuration-metadata.json
    org.springframework.boot.version
===> EXPORT
Reusing layers from image 'index.docker.io/itsrajivsrivastava/spring-petclinic@sha256:129f1e4231095c7504e01a4f233487b056eb28975b93f4dbb6195534bee4220e'
Adding layer 'paketo-buildpacks/bellsoft-liberica:helper'
Adding layer 'paketo-buildpacks/bellsoft-liberica:java-security-properties'
Adding layer 'paketo-buildpacks/bellsoft-liberica:jre'
Adding layer 'paketo-buildpacks/bellsoft-liberica:jvmkill'
Reusing layer 'paketo-buildpacks/executable-jar:class-path'
Adding layer 'paketo-buildpacks/spring-boot:helper'
Adding layer 'paketo-buildpacks/spring-boot:spring-cloud-bindings'
Adding layer 'paketo-buildpacks/spring-boot:web-application-type'
Adding 1/1 app layer(s)
Adding layer 'launcher'
Adding layer 'config'
Adding label 'io.buildpacks.lifecycle.metadata'
Adding label 'io.buildpacks.build.metadata'
Adding label 'io.buildpacks.project.metadata'
Adding label 'org.opencontainers.image.title'
Adding label 'org.opencontainers.image.version'
Adding label 'org.springframework.boot.spring-configuration-metadata.json'
Adding label 'org.springframework.boot.version'
*** Images (sha256:b6d6a0944600be3552c0b33e0a0759a12b422168484ffff55f9f9e0be4c93217):
      index.docker.io/itsrajivsrivastava/spring-petclinic:latest
      index.docker.io/itsrajivsrivastava/spring-petclinic:b1.20201009.190910
Adding cache layer 'paketo-buildpacks/bellsoft-liberica:jdk'
Adding cache layer 'paketo-buildpacks/maven:application'
Adding cache layer 'paketo-buildpacks/maven:cache'
===> COMPLETION
Build successful

Test Build Image

Pull image from Docker-hub:

docker pull itsrajivsrivastava/spring-petclinic

Run this pulled image on docker:

docker run -p 8080:8080 itsrajivsrivastava/spring-petclinic

Now , test on this browser: http://localhost:8080

How to build Dot Net application using TBS

TBS installation, setup yaml configuration, Github and DockerHub secret are same for Dot NET also.Deployment process is also same as Java on docker. There is a separate DotNet buildpack which will be injected to ASP.Net source code project.

Now, we will create TBS Dot Net image:

$ kp image create dotnetbuildtest \
  --tag index.docker.io/itsrajivsrivastava/dotnetbuildtest:latest \
  --namespace tbs-demo \
  --git https://github.com/rajivmca2004/DotNetBuild \
  --git-revision master

#Verify
$ kp image status dotnetbuildtest -n tbs-demo

If you face this in .Net apps:

Unable to start Kestrel.
System.Net.Sockets.SocketException (13): Permission denied
at System.Net.Sockets.Socket.UpdateStatusAfterSocketErrorAndThrowException(SocketError error, String callerName)
at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress

kestrel will bind to both ipv4 & ipv6. maybe  k8s env doesn’t let it bind to ipv6. Change env port 8080 to force it to only bind to ipv4

Fix– Add this in K8s deployment manifests.

Add this in Ku8s deployment manifest file:
         env:
         – name: PORT
           value: “8080”

FAQ