This article is the first of a multi-part comprehensive series on topics and considerations when designing, architecting, and building scalable, cloud-based software and big data solutions. The topics discussed here are applicable to different types of solutions such as enterprise, SaaS, big data, IoT, and more.
This article assumes that the product discovery, definition, design (UXUI), and information architecture (IA) phases are handled first, which leads naturally to the software and big data architecture topics discussed here.
The depth of discussion for each item may be limited since most topics presented can easily warrant their own article. Given this, the reader is encouraged to further explore specific topics of interest.
We begin by first discussing some common solution (aka application) types. At a very simplified high level, most cloud-based software solutions consist of a user interface, business logic and data persistence layer (e.g., web APIs), and data storage layer (database management system). Separate compute instances (physical or virtual servers) that host one or more layers are referred to as tiers.
The most common cloud-based solution type is called SaaS, or Software as a Service. The general simplified architecture is more or less as described above, and is characterized by subscription-based pricing models such as flat fee per user per month, flat fee per company per month, flat fee with increasing discount for longer up-front commitment (e.g., pay monthly vs annually), tier-based subscription pricing based on feature set (e.g., freemium, standard, premier), and so on.
SaaS applications are either single instance or multi instance, which simply refers to the number of compute instances deployed in the solution. Normally multi-instance solutions are used to separate concerns (via tiers and services), and to achieve performance and scalability goals.
SaaS applications are also usually characterized as either multi-tenant, dedicated, or a combination known as flex tenancy. This designation involves shared versus dedicated cloud computing and storage resources.
For SaaS applications used by many different users (e.g., Facebook) or organizations (e.g., Salesforce), often servers and databases are most effectively (cost, simplicity, …) deployed as shared multi-tenant resources, rather than having a single server instance dedicated to each user or organization. In certain instances however, and largely due to security concerns, dedicated solutions are needed by organizations. Flex tenancy describes the situation where a solution consists of both shared and dedicated resources.
Note that in multi-tenant solutions, the platform must be able to isolate data and data access per user and/or organization, despite sharing the same database instance(s). Also, availability issues will affect all tenants (users) of the system.
Finally, there are many different types of software solutions. Many of these are considered to be enterprise in that they are usually used by large organizations to address some of the organization’s functions and/or departments (e.g., sales, marketing, IT), and typically integrate with other solutions used by the organization.
Here is a non-exhaustive list with some examples:
- Static Site (Jekyll)
- Social media (Facebook, Twitter, Snapchat)
- Content management system - CMS (Wordpress)
- Enterprise resource planning system - ERP (Microsoft Dynamics, Oracle e-Business Suite)
- eCommerce (Amazon, Zappos)
- Customer relationship management - CRM (Salesforce, Pipedrive)
- Productivity and utility-based (Google Docs, Slack, Trello, Evernote)
- Accounting, payment processing, and billing (Quickbooks, PayPal)
- Email marketing (Mailchimp, ExactTarget)
- Purchasing, ordering, and inventory
- Business intelligence - BI
- Big data processing and analytics, batch and real-time streaming
- Internet of things (IoT)
It’s very common in enterprise software to integrate multiple enterprise systems and applications together, rather than to create a single application that addresses all enterprise needs. This integration architecture and framework is referred to as enterprise application integration (EAI).
Often EAI is used for data integration (aka enterprise information integration), or to provide a single unified user interface in order to allow the user to access data across disparate applications in a unified and consistent way. This is often associated with big data techniques and components such as ETL, data warehousing, business intelligence (BI), and so on.
Let’s first discuss the concepts of a network, data center, cluster, grid, and cloud before moving into specific details.
A computer network is a collection of computers that are connected in order to share resources. The internet is a perfect example of a massive network, while a home LAN or WiFi network is a good example of a smaller and more private network. Shared resources often include web pages, media, storage, app servers, printers, and so on. Nodes in a network identify each other and communicate via various protocols, with HTTP and TCP/IP being some of the most common.
While individual people and some companies may host application and data storage servers on-premise, often these servers are located in a data center. A data center is a facility that hosts many servers, associated components (e.g., networking, power, cooling), and all required infrastructure, security, and disaster protection. Amazon and Google for instance use many huge data centers located all over the world to support their offerings.
A cluster is a cost-effective group of computers networked on a high speed local area network (LAN), and are meant to address budget, performance, scalability, and availability requirements. They can be thought of as being a software-controlled single system with all nodes working together to accomplish the same task, or set of tasks. One can therefore think of a cluster as a single computer.
The terms distributed computing and distributed systems are terms used to describe systems where computer nodes coordinate and communicate with each other to achieve common goals, usually by leveraging computer clusters as described.
The terms grid and cloud describe somewhat similar concepts, with the difference being related to resource distribution and ownership. Both consist of a network of compute instances that operate together to provide on-demand, shared computing resources and data. Resources can include servers, services, networks, and data storage, for example.
The difference is that a cloud typically involves connected computation and shared resources that are administered, owned, and managed by a single party. A grid on the other hand is where the shared resources and units of computation are administered, owned, and managed by multiple parties. This series is focused primarily on clouds.
A cloud can be characterized as either public, private, community, or hybrid, if it’s a combination. This designation is based on ownership and access to the cloud resources. Clouds can also by physical or virtual, with AWS VPC being a great example of a virtual cloud platform.
Cloud-based Solution Components
A cloud-based solution can include many different components that must be carefully chosen and are highly specific to a given solution. The most common components are a client (front-end) and one or more back-end platforms such as servers and storage, along with supporting infrastructure and networking.
Servers are typically used to host and run applications and services (or microservices), including storage solutions such as databases. Clients are often classified using terms such as thick, thin, and so on. Typical clients include web browsers, mobile and tablet devices, and other physical devices such as a point of sale (POS) and parking garage ticket machines.
Common examples of solution components include:
- Web browsers
- Mobile devices and tablets
- API servers
- Web and static site servers
- Container servers (e.g., Docker)
- Servers hosting services such as a message bus/queue
- Server-less computation (e.g., AWS Lambda)
- Networking servers (e.g., Domain name servers or DNS)
- Load balancers
- Content delivery network servers (CDN)
- Identity providers (IdP)
- Source code and build servers
- Email servers
- Job scheduler
- Data storage and database management systems
- Transaction data stores (TDS/OLTP)
- Master data store
- Operational data store
- Data mart
- Data warehouse
- Data lake
- NoSQL/NewSQL DBMS
- Big data
- Data acquisition, extraction, ingestion, and integration
- Software, database, sensor, event, and message-driven
- Data processing and transformation
- Data access
- Business intelligence, data visualization, dashboards, and reporting
- Advanced analytics, data mining, machine learning, and artificial intelligence
- Data acquisition, extraction, ingestion, and integration
Functional and Non-Functional Goals and Requirements
The first step when designing a complete solution is to identify the functional and non-functional goals and requirements.
Functional requirements are those that describe elements of the solution, and what the solution can and must do. Examples of functional requirements are that the solution must have a native iOS and Android app, can send push notifications, offers an in-app chat feature, allows data exporting, integrates with key third party vendors, and so on.
While functional requirements help determine all necessary components, features, and functionality of a solution, they do not ensure the success of the solution, nor guarantee that the solution will function and perform properly under all likely usage scenarios.
Non-functional requirements refer to those that ensure success across all aspects of the solution that are not addressed by functional requirements, and often address things like reducing costs (money, time, rework, improvement, maintenance, …), improving operational efficiency, maximizing user experience and delight, and ensuring proper performant functionality under any and all likely use cases and usage scenarios (reliability, availability, and scalability).
Here is a list of some common non-functional requirements, some of which will be discussed in greater detail later.
- Modular and loosely coupled
- High quality
- Minimal technical debt
- Easy deployment and continous delivery
- Future resistant
Separation of Concerns
The next article in this series covers architectural patterns used in solutions, but first we should discuss the principle of separation of concerns (SoC) since it’s a driving force behind such architectures.
In many software applications, different parts of the code are often written in such a way as to be sectioned from other parts into concerns, yet are able to work together as a complete application by interacting with one another through well-defined interfaces between each.
Often this separation is realized through an architectural pattern called modularity, in which these sections are referred to as being isolated and encapsulated modules. Although not exhaustive, this separation allows for significantly improved code reuse, testing, module replacement (loose coupling), independent development, and maintainability.
In the case of SoC as applied to software code (as opposed to solution tiers for example), this is a form of the single responsibility principle in action. This principle simply states that each isolated concern (e.g., module) should be responsible for a single part of the software’s functionality, and nothing else. An example includes different layers in a multi-layered software architecture.
A similar concept related to object-oriented design and programming is known as general responsibility assignment software patterns, or GRASP. GRASP is a set of guidelines for assigning responsibility to classes and objects.
It’s worth mentioning that some aspects of software functionality apply to more than one, and in some cases all concerns, and can therefore not be totally isolated. These concerns are described as cross-cutting concerns, with logging being a perfect example. Aspect-oriented programming is a programming paradigm that addresses cross-cutting concerns separation and modularity.
Separation of concerns does not only apply to a software application’s code base however. It’s a concept that’s applicable to hardware, cloud components, networking (e.g., OSI model and IP suite), services, and so forth. Many of the architectures and topics discussed in this series are motivated by SoC.
This article covered cloud-based software and big data solutions, and many of the different application types and associated requirements upon which they’re built. We’ve also discussed concepts and terms surrounding cloud computing and cloud architectures, including some of the common components found in such solutions.
The next article in this series will cover specific architecture patterns, design patterns, and a deeper dive into solution components.