Posts

N-Tier Applications

N-Tier Applications -- N-Tier application architecture is the pattern that separates concerns of your systems into a layer of systems.  For example, the most common N-Tier application is a three tier application, which consists of the presentation layer, the domain layer, and data layer. The Layers Presentation Layer - The layer of your system that interacts directly with the user. In web projects this is will usually be some sort of javascript framework such as Angular, React, or many others. Application Layer - The layer that encapsulates all your business logic, domain concepts, and interacts with the data layer. In mos web projects, this will usually consist of an HTTP server such as IIS or Apache, and RESTful endpoints such Web API, Spring, or Express. Data Layer - The layer that stores and managers the application data. Popular data stores can be sql or nosql based, such as SQL Server, MYSQL, MongoDB, Cassanda. The advantage of N-Tier applications is that it em...

Attack Vector: Application DDoS

Quick review of Netflix article . Application DDoS There is a blogpost on Netflix which describes a new attack vector called Application DDoS. While traditional DDoS attacks rely on causing heavy network traffic to overload a system, application DDoS relies on heavy computation to bring down a microservice architecture. Let's start with how this is suppose to work. In a microservice architecture, you have a network of microservices that rely on each other. Calling one service can lead to that service calling multiple other services that call other services. This gives attackers the ability to make one request that actually makes many many more internal requests. By leveraging this idea, they can amplify their attack on the system. a single request in a microservices architecture may generate tens of thousands of complex middle tier and backend service calls This attack cannot be stopped by a traditional firewall because it may not know that the initial request is causing ...

Logging in a modern backend

In the modern day of distributed systems, the unsung hero of production debugging is having a centralized log systems and visualizer. A centralized log system is to have a central location that all logs from relevant systems would be dumped, for developers to navigate through to determine the health and confidence in a deployed system.  In today's development world, your systems will most likely consist of several systems (microservice architecture) or load balanced instances that make it hard to have your logs on one machine or database or other location.  The solution is to have all these systems pass their logs over to a central entity to be processed. Our system I first realized this need after working in a multi-tenant, multi-service environment.  To me just saying that screams head ache for anything deployed, where we don't have the ability to step through the code step by step. We previously set up our service to use Serilog, a structured logging framework...

Design Pattern: Abstract Factory

Abstract Factory Type: Object Creational Intent : Provide an interface for creating families of related or dependent objects without specifying their concrete classes.  This will give you the ability to have diverse implementations for a common interface. Rough Description : Abstract Factory is the interface that you define to encapsulate all the objects of a certain family.  From there you can create what are called "Concrete Factory", which actually instantiates the family of objects for you.  Your client or consumer will only know of the interface.  Somewhere in your code, you will set the interface to your Concrete Factory which will do the heavy lifting of instantiating your objects. Applicability A system should be independent of how its products should be created, composed, or represented. A system should be configured with one of multiple families of products. A family of related products need to be configured together, and relations enforc...

The Essentials: Design Patterns

Essential Patterns to Know In the new posts, I'll be focusing on some suggested design patterns and evaluating them based on the components described in the last post. I will be covering: Abstract Factory (Creational) Adapter (Structural) Composite (Structural) Decorator (Structural) Factory Method (Creational) Observer (Behavioral) Strategy (Behavioral) Template Method (Behavioral) The following design patterns have been organized into three categories: Creational, Structural, and Behavioral.  Additionally there are categorize them by the scope of the pattern, if it is on the class (structure) or the object (implementation). Pattern Types Creation Design Patterns deal with how you create objects.  Creational class patterns will defer object creation to subclasses, whereas Creational object patters defer it to another object. Structural Design Patterns deal with the composition of classes and objects.  Structural class patterns use inheritance ...

What is a Design Pattern?

What is a Design Pattern? Going through the the design patterns book, one of the introductory paragraphs is to define what a design pattern is and why they exist.  The book splits it up into the following components: Pattern Name and Classification  - All design patterns have a name that is universally recognized and can describe it in a small amount of terms. Intent  - This is a short statement that answers the following What does the pattern do? What is the rationale and intent? What particular design issue or problem are we trying to address? Also Known As  - Other well-known names this algorithm may go as Motivation  - A scenario that illustrates a design problem and how the organization of your code can solve a particular problem. Applicability - In what situations can this pattern be applied Structure  - A graphical representation of classes in the pattern and how they interact between objects Participants  - Classes or objects...

Design Pattern Principles - Interesting Interfaces

Interfacing with Interfaces One of the first lessons that the design pattern book threw at me was to "Program to an interface, not an implementation".  Having more experience under my belt, I've begun to notice the importance of decoupling requirements and code, such that we can create well-defined, manage-able code. So what does this mean to me?  For a long time, interfaces to me was more boilerplate code that I would have to set up to define an object that I already had.  But as I grew to work on more and more complex systems, its been a godsend to be able to use interfaces to dynamically swap components at run time, and to allow our architecture to be more flexible and robust. How do I use it? One of the greatest uses of interfaces is to facilitate the contract / handler pattern that allows us to decouple our implementation of a service, and allow us to swap in any other service that follows the same spec. Designing Your System for Change Let look into this b...