Pixytech

Lead Architect  •  Full Stack Engineer

Author: Pixytech

  • Building a TypeScript-First Frontend SDK for Capital Markets

    In my most recent engagement I led the architecture and delivery of a production frontend SDK for global capital markets applications – running on both browser and integrated desktop platforms, supporting delivery teams across London, New York, and Miami. The SDK itself took around a year to design and build from the ground up. In the period that followed, multiple projects across several teams were delivered on top of it. This post covers the architectural approach, the decisions behind it, and what distinguishes it from a conventional component library.

    Application layer Individual projects built on the platform Trading blotter Risk monitor Order management Operational tools Others… Framework SDK layer Native React and Angular — thin integration bridge over the core Angular UI SDK NG Zorro · Directives · DI adapters React UI SDK Ant Design · Hooks · DI adapters Core SDK Framework-agnostic TypeScript — no React or Angular dependency MVVMViewModel · State IoC / DIInversify · Discovery Blotter APIAgGrid · Streaming Forms APIRules · Validation ShellConfig-driven Dock layoutDockView · Persist ThemingAntD · NG Zorro InteropGlue42 · Notifs Charts / MapsHighcharts · MapLibre StreamingRxJS · WebSocket ObservabilityDatadog APM · Logging SecurityAuth · Impersonation AI-native contextAI-CONTEXT.md · Agent workflows CLI scaffold + deployment pipeline GitHub Actions · ArgoCD · Docker · dev / UAT / prod environments
    Platform architecture: three-layer SDK from Core through React/Angular framework layers to application projects

    Why a Component Library Is Not Enough

    The typical answer to “we need UI consistency across teams” is a component library: styled buttons, inputs, and data grids published as a package. That solves roughly 20% of the actual problem. What it does not address is where state lives, how view logic is tested independently of rendering, how a blotter in React and a blotter in Angular share identical behaviour, how complex form validation chains work across dependent fields, or how any of this is governed across a codebase that will run in production for five or more years with evolving teams.

    We built something with a different foundation: a TypeScript-first, framework-agnostic SDK where React and Angular are treated as equal native rendering targets – not one ported to the other. The framework choice for the view layer is a deployment concern, not an architectural one.

    The Biggest Pillar: MVVM and Dependency Injection

    The most important architectural decision in the entire SDK is the combination of MVVM and a first-class IoC dependency injection system. Everything else – the blotter API, the forms engine, the shell, the persistence service – builds on top of this foundation. Getting this right is what makes SOLID design principles apply naturally rather than being enforced through convention or code review discipline.

    The MVVM pattern enforces a hard separation between three things that most front-end codebases blend together: the view (a React component or Angular template), the ViewModel (a pure TypeScript class containing all business logic and state), and the model (data and services). The view is as thin as possible – it is just a template that binds to the ViewModel’s exposed properties and commands. It contains no business logic, no conditional branching, no data transformation. All of that lives in the ViewModel.

    This matters for several reasons. First, testability: because a ViewModel is a plain TypeScript class with no JSX, no Angular decorators, and no rendering framework knowledge, it can be instantiated and tested in isolation with zero UI involvement. Business logic that would otherwise require mounting components, simulating events, and asserting on DOM output is instead tested as straightforward unit tests against TypeScript classes. Second, reusability across stacks: the same ViewModel powers both the React and Angular implementations of a feature. The React developer writes a React template; the Angular developer writes an Angular template; both bind to the same ViewModel and get identical behaviour. The core business logic is written once, not twice. Third, long-term maintainability: the boundary between pure TypeScript and framework-specific code is explicit and enforced. New engineers know exactly where business logic lives and where rendering concerns live – there is no ambiguity about which side of the line a given piece of code belongs on.

    The dependency injection system is built as a wrapper around Inversify, providing a first-class, high-performance, on-demand service resolution mechanism. Rather than relying on Angular’s built-in injector (which only works in Angular) or React context (which is not really DI at all), the SDK maintains its own IoC container that works identically in both stacks. Services are registered against interfaces, not concrete implementations – which is how the D in SOLID (Dependency Inversion) actually applies in practice rather than in theory. Angular gets a transparent DI bridge that maps the SDK container into Angular’s own injector, so Angular components consume services normally without knowing the underlying mechanism. React gets a hook-based integration layer that resolves ViewModel and service instances from the same container on demand.

    The SDK also implements a service discovery pattern on top of Inversify – services can be resolved by capability rather than by concrete type, which means consuming code depends on abstractions and the container decides which implementation to provide at runtime. This makes the single responsibility principle and open/closed principle apply naturally: adding new behaviour means registering a new implementation, not modifying existing classes.

    The net result is a codebase where the vast majority of logic is pure TypeScript – framework-agnostic, fully testable, consistently structured across both stacks. React and Angular contribute only what they are actually good at: native component rendering and template binding. The hard parts belong to the SDK.

    Monorepo Structure

    The SDK lives in an Nx monorepo with a strict separation between layers. The top level contains four library packages and a set of reference applications:

    • Core library – the framework-agnostic foundation: all MVVM abstractions, IoC container, services, streaming, state, theming, and UI component logic. No dependency on React or Angular.
    • React library – thin React integration layer. Hooks that connect the view to ViewModels, React-native component wrappers, Redux integration, and React-specific layout implementations.
    • Angular library – thin Angular integration layer. Directives that connect the view to ViewModels, Angular-native component wrappers, Angular module structure, and DI bridge to the core container.
    • CLI – project scaffolding tool that generates new applications preconfigured with the full SDK, authentication, theming, dock layout, CI/CD pipelines, ArgoCD deployment templates, and AI assistant context.

    Nx boundary rules enforce that only the React and Angular libraries may import from Core – consuming applications never reach into Core directly. This keeps the dependency graph clean and upgrades tractable.

    Platform Architecture

    The SDK is structured in three layers:

    • Core SDK – the TypeScript foundation covering IoC/DI, MVVM, state management, messaging, configuration, logging, streaming, notifications, theming, testing utilities, base components, desktop interop, security, instrumentation, and APM integration via Datadog.
    • Framework SDK layer – the Angular UI SDK (NG Zorro components, framework directives, DI adapters) and React UI SDK (Ant Design components, framework hooks, DI adapters), plus shared packages for application shell and data services.
    • Application layer – individual products (trading blotters, risk monitors, order management, operational tools, and others) sitting on top of a unified application shell, deployable to browser or integrated desktop environments.

    The platform targets Windows, macOS, Chrome, tablet, and integrated desktop interop – all from a single codebase.

    What the SDK Provides

    Scaffolding CLI with Full Deployment Pipeline

    The scaffolding CLI does considerably more than generate a starter project. In a few commands it produces a fully working application ready to build and deploy, including:

    • GitHub Actions workflows – pre-configured CI pipelines covering lint, test, build, and Docker image publishing, wired to branch conventions out of the box
    • ArgoCD deployment manifests – Kubernetes deployment YAML templates pre-structured for standard client environments: dev, UAT, and production, with environment-specific configuration overlays already in place
    • Docker configuration – production-ready Dockerfiles and compose files aligned to the organisation’s container standards
    • Full SDK integration – authentication, theming (AntD for React, NG Zorro for Angular), dock layout, widget architecture, and AI assistant context all wired up before the first line of business code is written

    The result is that a new project goes from a CLI command to a deployable, environment-aware application in minutes rather than days. Infrastructure decisions that would typically consume the first sprint of any new project are already made and encoded in the generated output. Teams start from working, not from blank.

    Observability: Logging, Instrumentation, and Datadog APM

    Observability is a first-class SDK concern, not something left to each application team to figure out independently. The SDK ships a structured logging service, a client-side instrumentation layer for tracking user interactions and application events, and a built-in integration with Datadog APM. Every generated project comes with Datadog configured out of the box – real user monitoring, error tracking, and performance traces are available from day one without any per-application setup. Support teams get consistent, queryable telemetry across all applications in the portfolio rather than fragmented logging from teams who each chose a different approach.

    Config-Driven Shell and Dock Layout

    The application shell is entirely config-driven. Navigation, panels, workspace layouts, and module registration are declared in configuration rather than code. The dock layout system wraps a proven open-source dock library, exposing a component API that handles panel creation, tear-off, resize, and state persistence. On integrated desktop platforms, the same configuration drives the interop layer – window management, application channels, and cross-application registration – without the consuming application needing platform-specific code.

    Persistent State Service

    Any component or screen can register with the persistence service. Column widths, panel positions, filter state, sort order, and active tabs are all serialised and restored on page load. A user who refreshes their browser returns to exactly the state they left, including their dock layout arrangement. This is a cross-cutting platform service, not something individual teams implement per application.

    Blotter API

    The blotter module wraps a high-performance data grid library, exposing both client-side and server-side row model implementations through a consistent SDK API. Teams configure a blotter via a metadata endpoint – column definitions, grouping, sorting, filtering, row actions – and the SDK handles grid wiring, streaming row updates via RxJS observables, server-side query specification, and toolbar integration. A team building a new blotter writes configuration and a ViewModel, not grid framework boilerplate.

    Forms API with Rule Engine

    The forms module provides a rich field API with client-side and server-side validation, RxJS-based dependency tracking between fields, and a rule engine that triggers visibility, validation, and value changes in response to field state changes. A field change can cascade through a declared dependency graph – disabling fields, firing async validation, populating dependent lookups – all configured rather than manually wired in component code. Backend validation rules integrate into the same pipeline so client and server errors surface consistently.

    Theming: Ant Design with Dark Mode Foundation

    The theme system is built on Ant Design (React) and NG Zorro (Angular) with dark mode as the primary target, appropriate for trading floor environments. Design tokens cover semantic colour for financial data (positive/negative P&L, alert states, neutral hierarchies), flex-based layout primitives, typography, and component-level overrides. Tokens are exposed as CSS custom properties and typed constants, applied globally through the SDK theme service – individual components never hardcode visual values.

    Charts, Maps, and Notifications

    Charts wrap a commercial charting library with config-driven components and streaming data support. Maps wrap an open-source mapping library with config-driven components for geographic data use cases common in commodities and energy domains. The notification API integrates with the desktop interop layer so in-app notifications can be promoted to OS-level desktop notifications and cross-application broadcasts.

    Built-in Support Mode and Impersonation

    The SDK includes a built-in impersonation service for support and operations teams. An authorised support engineer can assume a user’s identity and view the application in read-only mode that exactly reflects what that user sees – layout, data permissions, and persistent state. This is wired into the security layer and surfaced through the shell UI without any per-application implementation work.

    AI-Native Development

    One of the more distinctive aspects of this SDK is that it is explicitly designed for AI-assisted development, not just human developers. Every package ships with a structured context file, and the monorepo uses a hierarchical routing system so that an AI coding agent working on a specific task reads only the relevant context – not the entire codebase at once.

    The routing is task-specific: an agent working on the data grid reads the blotter context; an agent working on forms reads the forms context; an agent working on theming reads the theme context. Each context file covers architecture patterns, naming conventions, state management approach, styling guidelines, and the service locator pattern – everything the agent needs to generate code that conforms to SDK standards without human supervision of every detail.

    The SDK ships agent workflow configurations for Claude, Cursor, and Roo – pre-configured with mandatory reading rules and task-specific routing. Projects generated by the CLI receive these configurations automatically, so every new project is AI-ready from day one. Developers are required to update context files whenever they add or modify features – the AI context is treated as a first-class deliverable and validated in CI alongside code changes. The result is governed AI-assisted development: agents operate within SDK standards by default, producing code that a senior engineer reviewing it would find indistinguishable from hand-crafted output.

    Governance

    Keeping standards intact as teams grow and rotate is the hardest long-term challenge. The SDK enforces governance through several mechanisms:

    • Nx module boundary enforcement – packages import only from declared dependencies; cross-layer imports and circular dependencies are rejected at build time
    • Semantic versioning with deprecation windows – no API or component is removed without prior deprecation warnings across at least two minor versions
    • AI context files as a living contract – CI validates that context files are updated alongside code changes
    • Storybook per library – every component has stories; visual regression is part of the pipeline
    • Platform-level support infrastructure – impersonation, Datadog APM, structured logging, instrumentation, and a support wiki are first-class SDK features, not per-project afterthoughts

    Outcome: Months to Weeks

    The headline result is straightforward: applications that previously took months to deliver are now delivered in weeks, with consistent look and feel, consistent behaviour, and a codebase that a new engineer can orient to quickly because the patterns are identical across every project in the portfolio.

    The SDK absorbs all the platform complexity – grid integration, RxJS streaming, IoC container setup, desktop interop, theme inheritance, dock layout persistence, form validation chains, Datadog APM, and the entire path from build to production deployment – so that consumer applications contain the minimum possible code. A new application is largely configuration and business-specific ViewModel logic. The hard problems are already solved.

    That is the measure of a good platform: the teams building on top of it should rarely have to think about it.

  • Enterprise configuration management

    Almost every application requires some form of configuration information. This information can be as simple as a database connection string or as complex as multipart and hierarchical user preference information. How and where to store an application’s configuration data are questions you often face as a developer.

    Any large enterprise application has many moving blocks. They all need to be configured for a proper working of the application. As the application size increases or for scalability the same configuration has to be repeated in different applications. For most applications once the configuration has been changed the application needs to be restarted.

    Sample Code (create a blank console project, add json.net nuget)

    using Newtonsoft.Json;
using Newtonsoft.Json.Linq;
using System.Collections.Generic;
using System.Linq;

namespace CM
{
    // configuration management API, 
    //1. allow clients specify typesafe models for configuations
    //2. Store flat data on server (table) which is easy to edit
    //3. can be extended to have inheritance of values (overrides)
    //4. can be extended to lock / unlock certain property by admins etc.
    
    class Program
    {
        //Sample configuration model
        internal class SampleConfigModal
        {
            public SampleConfigModal()
            {
                Address = new Address();
            }
            public string Name { get; set; }
            public Address Address { get; set; }
            public int Age { get; set; }


        }
        public class Address
        {
            public string Street { get; set; }

        }

        // this is how client api will look like
        static void Main(string[] args)
        {
            // sample client code
            var data = new SampleConfigModal() { Name = "Rajnish", Age = 18, Address = new Address() { Street = "Oxley" } };

            // save Configuration
            SaveConfiguration("app", "section", data);

            //get Configuration
            var data2 = GetConfiguration("app", "section");
        }

        // Client side framework api -> call to rest end point
        private static T GetConfiguration(string appName, string SectionName) where T : new()
        {
            var defaultValue = new T();
            var samplePayload = JsonConvert.SerializeObject(defaultValue);
            var payload = GetConfiguration(appName, SectionName, samplePayload);
            return JsonConvert.DeserializeObject(payload);
        }

        // Client side framework api -> call to rest end point
        private static void SaveConfiguration(string appName, string SectionName, T data)
        {
            var payload = Newtonsoft.Json.JsonConvert.SerializeObject(data);
            SaveConfigurationa(appName, SectionName, payload);
        }


        //---------------------------------------- Server Code -------------------------- 
        //-------------- server has no knowledge of configuration structure or model

        private static Dictionary<string, string> storage;

        private static void SaveConfigurationa(string appName, string SectionName, string payload, string enumForHierarchyLevel = null)
        {
            // transformer
            var section = string.Format("{0}.{1}", appName, SectionName);
            var data = (JObject)JsonConvert.DeserializeObject(payload);
            var keyValueData = Flatten(data, section);

            // check if user has permission for level overrides
            // store with proper overides

            // store the flat list in sql or data 
            //| KEY |           |Value|            |OverrideType| - default,sysadmin,appadmin,groups,user etc
            //app.section.Name, Rajnish
            //app.section.Address.Street, Oxley
            //app.section.Age, 18

            storage = keyValueData;
        }

        private static string GetConfiguration(string appName, string SectionName, string samplePayload)
        {
            var section = string.Format("{0}.{1}", appName, SectionName);
            var data = (JObject)JsonConvert.DeserializeObject(samplePayload);
            var keyValueSample = Flatten(data, section);
            // update data from sql or data store
            // apply property override rules and get value from overrides if exists
            var keyValueData = keyValueSample.Select(x => new KeyValuePair<string, string>(x.Key, storage[x.Key]));

            //read these
            //app.section.Name, Rajnish
            //app.section.Address.Street, Oxley
            //app.section.Age, 18

            UnFlatten(data, section, keyValueData);

            var formatedData = JsonConvert.SerializeObject(data);
            /*
             * {
                  "Name": "Rajnish",
                  "Address": {
                    "Street": "Oxley"
                  },
                  "Age": "18"
                }
             * */
            return formatedData;

        }
        
        // Server side json helper

        private static void UnFlatten(JObject jsonObject, string prefix, IEnumerable<KeyValuePair<string, string>> data)
        {
            foreach (var item in data)
            {
                var keyName = item.Key.Substring(prefix.Length + 1);
                var storageValue = item.Value;
                if (keyName.Contains("."))
                {
                    var keys = keyName.Split('.');
                    var jtoken = (JToken)jsonObject;
                    foreach (var k in keys)
                    {
                        jtoken = jtoken.SelectToken(k);
                    }
                    ((JValue)jtoken).Value = storageValue;
                }
                else
                {
                    jsonObject[keyName] = storageValue;
                }
            }
        }

        private static Dictionary<string, string> Flatten(JObject jsonObject, string prefix)
        {

            IEnumerable jTokens = jsonObject.Descendants().Where(p => p.Count() == 0);
            Dictionary<string, string> results = jTokens.Aggregate(new Dictionary<string, string>(), (properties, jToken) =>
            {
                properties.Add(string.Format("{0}.{1}", prefix, jToken.Path), jToken.ToString());
                return properties;
            });
            return results;
        }
    }
}

  • BoundedContext – DDD

    Earlier in the article Software Architecture Patterns we briefly discussed domain driven design. In this article we will take a real example and dive into best practices and design of solution based on hypothetical problem or scenario.

    Bounded Context is a central pattern in Domain-Driven Design and It is the focus of DDD’s strategic design section which is all about dealing with large models and teams. The DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships.

    Strategic design  deals with situations that arise in complex systems, larger organizations, interactions with external system.Strategic design decisions are made by teams, or even between teams. Strategic design enables the goals of DDD to be realized on a larger scale, for a big system or in an application that fits in an enterprise-wide network.

    DDD is about designing software based on models of the underlying domain. A model acts as a Ubiquitous language to help communication between software developers and domain experts. It also acts as the conceptual foundation for the design of the software itself.

    It is hard to model a larger domain and build a single unified model. In real world, small domain models are build and together they represent the larger domain. Now lets image a real world example from electricity utility – smart meters ! –  here the word “meter” meant subtly different things to different domain experts coming from different parts of the organization. Lets try to understand the domain and try to break into sub domain models.

    Smart meters are the next generation of gas and electricity meters and offer a range of intelligent functions.The smart metering system is made up of: one electricity smart meter, one gas smart meter, a communications hub and an in-home display unit-the smart energy monitor on which you can view your energy.Smart meters measure actual, total gas and electricity usage and put consumers in control of their energy use, allowing them to adopt energy efficiency measures that can help save money on their energy bills.

     

    smart meter

     

    Now lets split the into domains and sub domains

    smart domain

     

    In the above diagram the subdomain build on foundation however one sub domain is interrelated to one or more other sub domain. They don’t exists in isolation in real world. The total unification of the domain model for a large system will not be feasible. So instead DDD divides up a large system into Bounded Contexts, each of which can have a unified model.

    A bounded context typically represents a slice of the overall system with clearly defined boundaries separating it from other bounded contexts within the system. If a bounded context is implemented by following the DDD approach, the bounded context will have its own domain model and its own ubiquitous language.

    A bounded context is the context for one particular domain model. Similarly, each bounded context (if implemented following the DDD approach) has its own ubiquitous language, or at least its own dialect of the domain’s ubiquitous language, entities, services etc. as shown below.

    Bounded Context

    Bounded Contexts have both unrelated concepts – such as a support ticket only existing in a customer support context, but also share concepts such as products and customers both exists in sales and support contexts.

    A large complex system can have multiple bounded contexts that interact with one another in various ways. A context map is the documentation that describes the relationships between these bounded contexts. It might be in the form of diagrams, tables, or text.

    In the next series we will dive into how we can apply CRQS (Command Query Responsibility Segregation Pattern) and vertically slice the layered architecture to deliver the highly scalable yet composite solution.

  • Software Architecture Patterns

    Extreme Programming (XP) is one of the more well known Agile methodologies. It is a programmer-centric methodology that emphasizes technical practices to promote skillful development through frequent delivery of working software.This methodology takes “best practices” to extreme levels and that’s why its named as Extreme Programming. Code reviews are a good example of Extreme programming. If code reviews are good, then doing constant code reviews would be extreme; but would it be better? This led to practices such as pair-programming and refactoring, which encourage the development of simple, effective designs, oriented in a way that optimizes business value.

    Extreme Programming defines 4 basic activities (coding, testing, listening & designing) and several practices like Pair Programming, Planning game, Test driven development, continuous integration, design improvement, coding standards, collective code, simple design etc.

    Projects suited to Extreme Programming are those that:

    • Involve new or prototype technology, where the requirements change rapidly, or some development is required to discover unforeseen implementation problems
    • Are research projects, where the resulting work is not the software product itself, but domain knowledge
    • Are small and more easily managed through informal methods

    Below are some software development process based on a concept of Extreme Programming and are about how to approach your design.

    Test driven design (TDD)

    tdd

    TDD is a software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the software is improved to pass the new tests, only. It offers them a technique to explore the concepts behind the customers requirements, questioning that requirement and uncovering likely pitfalls. The developer can deliver these benefits without spending valuable time building and perfecting a graphical user interface. it stops developers from over engineer the product and encourage them to think from different prospective.

    TDD relies on the repetition of a very short development cycle :

    • Write an automated test case that defines a new feature – no code yet, so test will fail
    • Produce the minimum amount of code to pass that test
    • Refactor the new code to acceptable standards.

    Domain driven design (DDD)

    DDD is the process of being informed about the Domain before each cycle of touching code. Domain is a set of functionality that you are attempting to mimic that lies outside of your application.Domain Driven Design (DDD) is about mapping business domain concepts into software artifacts.Driven Design (DDD) focuses on the core model (the domain) and tries to keep other stuff like UI’s and databases separate.Domain Driven Design is all about understanding the customer real business need and emphases focuses more into the business need not focusing on the technology.

    It promotes important agile principles:-

    • Maintain the projects primary focus on the core domain of the delivery
    • Use models to refine a complex design and
    • Get the key team members together to collaborate deeply to derive their designs.

    Domain modeling and DDD play a important role in Enterprise Architecture (EA). Since one of the goals of EA is to align IT with the business units, the domain model which is the representation of business entities, becomes a core part of EA. This is why most of the EA components (business or infrastructural) should be designed and implemented around the domain model. Domain driven design is a key element of Service Oriented Architecture (SOA) because it helps in encapsulating the business logic and rules in domain objects. The domain model also provides the language and context with which the service contract can be defined.

    Domain driven design effort begins where domain modeling ends.

    There should be more focus on domain objects than services in the domain model.

    • Start with domain entities and domain logic.
    • Start without a service layer initially and only add services where the logic doesn’t belong in any domain entity or value object.
    • Use Ubiquitous Language, Design by Contract (DbC), Automated Tests, CI and Refactoring to make the implementation as closely aligned as possible with the domain model.

    From the design and implementation stand-point, a typical DDD framework should support the following features.

    • It should be a POCO based framework.
    • It should support the design and implementation of a business domain model using the DDD concepts.

    Bounded Context is a central pattern in Domain-Driven Design and It is the focus of DDD’s strategic design section which is all about dealing with large models and teams. – for more details on bounded context continue reading ddd here – series 2 of DDD.

    Behaviour driven design (BDD)

    BDD is a software development process based on Test-driven Development (TDD), that combines the general techniques and principles of TDD with ideas from Domain-driven Design (DDD) and Object-oriented Analysis and Design to provide software developers and business analysts with shared tools and a shared process to collaborate on software development, with the aim of delivering “software that matters”.While it is a refinement to TDD, it concentrates in understanding the user’s behaviour, and yields nicely to a good acceptance of the end system. In the though process means thinking from outside the system in. The benefit is that it offers a more precise and organized conversation between developers and domain experts

    BDD is also often heralded because BDD testing tools can be arguably more human readable to non-developers such as Domain Experts

    Event driven architecture (EDA)

    -TODO

    Command Query Responsibility Segregation Pattern (CQRS)

    -TODO

  • Cloud Computing

     

    Cloud

    You’re probably using cloud computing right now, even if you don’t realize it. If you use an online service to send emails, edit documents, watch films or TV, listen to music, play games, or store pictures and other files, it’s likely that cloud computing is making it all possible behind the scenes.

    Cloud computing stack

    Most cloud computing services fall into four broad categories: On Premises, infrastructure as a service (IaaS), platform as a service (PaaS) and software as a service (SaaS).

    Cloud Solutions Model

    IaaS  – Infrastructure as service

    This is where pre-configured hardware is provided via a virtualised interface or hypervisor. There is no high level infrastructure software provided such as an operating system, this must be provided by the buyer embedded with their own virtual applications.

    PaaS – Platform as service

    PaaS goes a stage further and includes the operating environment included the operating system and application services. PaaS suits organisations that are committed to a given development environment for a given application but like the idea of someone else maintaining the deployment platform for them.

    SaaS – Software as service

    Saas offers fully functional applications on-demand to provide specific services such as email management, CRM, web conferencing and an increasingly wide range of other applications & services.

    Type of Cloud deployment

    Based on the security and management required, the clouds can be built in following three ways to suit the needs of the businesses:

    Public cloud
    Public clouds are owned and operated by a third-party cloud service provider, which delivers computing resources such as servers and storage over the Internet. Microsoft Azure is an example of a public cloud. With a public cloud, all hardware, software and other supporting infrastructure are owned and managed by the cloud provider. You access these services and manage your account using a web browser.

    Private cloud
    A private cloud refers to cloud computing resources used exclusively by a single business or organisation. A private cloud can be physically located on the company’s on-site data centre. Some companies also pay third-party service providers to host their private cloud. A private cloud is one in which the services and infrastructure are maintained on a private network.

    Hybrid cloud
    Hybrid clouds combine public and private clouds, bound together by technology that allows data and applications to be shared between them. By allowing data and applications to move between private and public clouds, hybrid cloud gives businesses greater flexibility and more deployment options.

    Community Cloud

    Type of cloud hosting in which the setup is mutually shared between many organisations that belong to a particular community, i.e. banks and trading firms. It is a multi-tenant setup that is shared among several organisations that belong to a specific group which has similar computing apprehensions. The community members generally share similar privacy, performance and security concerns.