Mobile applications have taken a center stage for the past few years, and with the continuous improvements in mobile technology, we will see more and more applications embracing the mobile platform. However, as an Architect and a developer, building a mobile application that will work across multiple platforms, and yet keep the code as sleek as possible is a daunting task. This was the challenge I faced when designing the Shopping Guru app that helps in making the most out of your online purchases. In this article, I will cover how I went about making this cross-platform app with a high amount of code reusability.

Cross-Platform Mobile Application Key Challenges

For the sake of discussion, I’m summarizing the two core requirements for the Shopping Guru app so that we can understand the challenges and the key aspects of the design better.

• Do periodic checks to generate price drop and product availability alerts.
• Facilitate goal-driven purchases by organizing these into projects. For example, create a project to set up a home theater.

We briefly touched upon a couple of challenges in the introduction. But, let’s highlight the key challenges keeping the 2 dominant mobile platforms – iOS and Android.

• How to improve the code reusability? A big part of this question is how to use the same programming language? As we know, iOS supports Swift and Objective-C. Whereas, Android supports Java and Kotlin.
• How to manage the app data in the cloud? For example, iOS offers iCloud functionality to store data. But, the moment you add Android into the mix, you do not want to have multiple ways of managing data in the cloud, especially, if your app has cloud-based processes that need access to this data. In the case of Shopping Guru, we needed access to the data to generate price drop alerts and to check whether a previously unavailable product is now available.
• How to handle platform-specific interactions that originate “from” the common code? For example, when a price drop occurs generate a notification. The price drop check can be done in a platform-independent reusable code. However, the notification has to be generated using platform-specific features.
• How to handle resources, such as externalized text and images?

As you can see, if we don’t get hold of these aspects early on, the code could get quite messy.

Application Architecture

After doing a few prototypes, I decided to split the application into 2 parts.

1. Mobile App: This is the app itself that contains primarily the user interaction code with basic logic.
2. Cloud-based REST API: This handles the core business logic and provides additional capabilities to improve performance, such as caching and throttling calls to the Vendor API. The Vendor API is used to search and retrieve items.

Mobile Application Design

The app comprises the following key components.

• UI: The user interface and associated code. This layer is implemented separately for iOS and Android. The majority of the application code is written in Java. For Android, that’s pretty straight-forward. And, for iOS, I used Multi-OS Engine, which provides a Java runtime on iOS and makes it possible to write pretty much all of the code in Java. You still need to use Xcode to create the storyboard and generate the skeleton code (such as the controller header and implementation files). From that point, you can use Multi-OS Engine’s IDE plugins to generate Java artifacts. It’s free and the app performance was reasonable.
• Core: This component provides common business logic and maximum code reusability. It also handles common resources, such as externalized text, images, and configuration files. For outgoing calls from the Core module to platform-specific implementation, I decided to have specific interfaces that will be implemented by the respective platform-specific module. For example, both Android and iOS modules implement a NotificationManager interface to provide notification management functionality. The UI code passes these module instances to the Core module at initialization time.
• Data Refresh: This component helps in fetching prices periodically, especially when the app is running in the foreground. Again, this is a reusable component.
• The app uses the following custom libraries.
  • NetworkMonitor: This is used for monitoring the network status, such as when the device is connected to WiFi versus when its connected to the cellular network. Depending on the type of connectivity, the app automatically switches network usage to avoid/minimize cellular data usage.
  • AnalyticsManager: This is used to publish opt-in app usage metrics with user consent.

With this approach, I could significantly improve code and resource reusability.

REST API Design

The REST API acts as the brain of the solution and comprises the following key components.

• The API Gateway + Lambda combination provides the REST API layer that the app would use for needs like searching items and retrieving item prices. It interacts with the Vendor API behind the scenes on a need basis to fetch the latest data. Also, it can do price drop and product availability checks periodically.
• DynamoDB is used to cache the frequently accessed data.
• It also offers a platform-agnostic way of managing app data. In fact, for the most part, the cloud-based components do not even care about the device’s actual platform.

Apart from resolving some of the challenges cited earlier, cloud-based components provide additional flexibility to add improvements and enhancements that do not require changes to the mobile app. This saves significant time to deliver enhancements to the end-users.

Development Setup

• I chose Android Studio as the core IDE since it is quite convenient for Android development. Besides, Multi-OS Engine offers a neat plugin to generate Java artifacts.
• Xcode is used on a need basis when editing the storyboard and creating initial files. Also, it is used to publish builds to App Store Connect.
• The build uses the gradle framework. Each module has a build.gradle file.
• For cloud deployment, I am using the AWS CloudFormation templates. This makes it easy to add more regions, as needed, literally in a matter of minutes!

Resources

• Multi-OS Engine Getting Started Guide
• How To Design Applications For Cloud (SaaS)?
• How To Create a Multi-Tier Stack Using AWS CloudFormation?

Developing a cross-platform mobile application requires a focused approach to consistently identify platform-specific versus reusable code. Once you establish this basic rule of thumb, you can extend it further to identify components that can be reused across multiple applications (like the NetworkMonitor and AnalyticsManager in this article). And, I hope this article gives you a good enough starting point to build a prototype for your mobile application and see if it would meet your needs.

Happy developing!
– Nitin

If you liked this post, you will find my AWS Advanced For Developers course helpful that focuses on many such best practices and techniques to design and deploy real-world applications in AWS.

The post How To Design A Cross-Platform Mobile Application? appeared first on Cloud Nine Apps.

Following are the highlights of this release.

• Share an item with Shopping Guru from a product page on Amazon’s mobile application or website.
• Product Availability Alerts: When the demand is high, several commonly needed items become unavailable quickly. Just share the item that is currently unavailable from Amazon’s mobile application or website, and Shopping Guru will alert you when the item becomes available.
• Launch Amazon’s mobile app (if installed) when buy item is clicked.
• Major improvements to price checks and generating price drop notifications.

Check it out now! We would love to hear your feedback.

The post Shopping Guru 1.2 Released appeared first on Cloud Nine Apps.

Many Software Architects, Developers, and Leads face this question for their projects – whether they should document their projects? If yes, how much? No, we are not talking about the required documentation that almost every software project needs, like the customer-facing documentation. By “internal documentation”, I am talking about technical documentation like Architecture and Design documents. In this post, we will discuss how to approach such internal documentation.

Why Document Your Project?

This is the most important question. Simply put, what is your intent behind documentation? Are you planning to use it as a tool that can help you build more quality software or are you simply putting together some artifacts for the sake of it? And, this is not just a question for the Architects and Designers, but also the entire team. After all, when you are investing time and effort in the documentation, most of the team should benefit from it. Projects that take the approach of using documentation as a tool to build more quality software not only benefit from it, but these have more useful documentation.

Pros of Technical Documentation

The following are some of the common benefits of having technical documentation.

• It helps validate the approach, design, and implementation.
• It can help establish the core concepts and avoid common misunderstandings.
• The same artifact can benefit multiple aspects of the software life cycle. Remember that the same document may be consumed in different ways by different team members. For example, while a developer may look at it for their implementation, a quality assurance team member can use it for writing their test cases.
• It can significantly help in ramping up new team members who join the project later.
• It establishes transparency in sharing information that could benefit the entire team.
• By keeping it up-to-date, it can help avoid redundant communication.

Cons of Technical Documentation

Of course, documentation comes at a cost. These are not necessarily cons of documentation but are associated with it.

• It requires a time investment.
• It runs the risk of getting outdated as the project progresses. This is often the case when documentation is produced for the sake of it but is not being used for anything meaningful.

So, as you can see, it all boils down to the point about the purpose of the documentation.

How To Approach Technical Documentation?

I am a big believer in using documentation as a tool to deliver quality software. Hence, I like to invest time to make it more meaningful. Here are some useful tips that I like to consider for the documentation.

• Establish the core concepts: Having a simple section like glossary is good. But, often you, as a designer, may have some core concepts that you would like the team to understand. Just like in the business world, there are key driving factors, there are certain core concepts that are key to the functioning of your application. For example, specific data model elements, algorithmic constructs that can help the team understand how the system is architected and what was the thought process behind it. It is interesting to come back to this section a year later and find whether these are still applicable!
• Organize effectively: Avoid clubbing multiple types of content in the same section. It not only makes it harder to understand, but it could create confusion and make it difficult for other team members to extract information. For example, instead of including data model, deployment, performance altogether, consider splitting these into separate sections. For more complex projects, it may be worth having dedicated documentation for certain components/services and having links to these from the overall project-level documentation. This way, team members focused on those components can find information more easily. It would also make it easier to delegate ownership of maintaining this documentation.
• Be concise: The good thing when you write is you can try to articulate your thoughts as concisely as possible. I like to use bullets over paragraphs especially when the topic is dense.
• Keep it simple: That goes without saying. Avoid the use of complex words and jargon that are not helpful. Of course, if some complex terms are vital from an understanding perspective, use these, but make sure that these have been clarified.

What Should I Include In My Software Design Document?

A Software Design Document (a.k.a. SDD) is a living commentary of your project. The following are some key pieces of information that I would like to include in an SDD.

Note: I talk about multiple diagrams as each diagram helps in analyzing the application differently, and collectively these help in gaining a more complete picture.

• Glossary: This captures the key terms that consumers of the documentation should be familiar with. For example, any important abbreviations you are using throughout the documentation.
• Architecture Overview: An overview of the System Architecture. This is a very high-level blueprint of your application, such as an n-tier architecture that will typically not change much over the life span of the application.
• Key Concepts: We talked about these earlier in this post. This section should cover the key concepts and how these work together to make your application function. Also, coming up with meaningful names for these concepts can often help you convey a specific point easily as opposed to always explain what you are talking about.
• High-Level Design: This should capture the overall system design, key components, and their dependencies. Often a UML Component Diagram can come in handy here. The idea here is to give sufficient guidance to individual components’ leads to understanding how they fit in the overall picture. At the same time, giving them at least some level of flexibility in their specific component design, as appropriate.
• Deployment Diagram: If there is one diagram you must-have in almost every SDD, then this is the one. It helps in establishing key details like deployment nodes, which components will run on these, ports exposed, protocols used, and the direction of communication. This is often accomplished via a UML Deployment Diagram.
• Data Model: This is at the heart of many enterprise applications. At a minimum, this should include key entities and their relationships. Often, this will be the input for the database implementation. Entity-relationship Diagrams or ER Diagrams are often used to capture this.
• Class Diagrams: Having one or more Class Diagrams that cover the key classes and their relationships can help the team members build a better understanding. Here, you should focus on core classes that contain business logic and avoid cluttering with classes that are only relevant from the data perspective. Those would typically have been covered in the Data Model anyway.
• Interaction Model: This helps in understanding component interaction in chronological order. This is often captured via UML Sequence Diagrams.
• Compatibility Matrix: If your application has specific compatibility requirements, such as operating system version, library versions, etc it is worth capturing these. These details are extremely important for testing as well as for customer documentation.
• Dependencies: Any third-party libraries or other dependencies that your application requires. This is important for technical aspects like builds. It is also important for legal because, at times, developers may pick up a library that may not be the best choice from a legal standpoint. So, the sooner you can jot down this list and get clearance from stakeholders, the better.
• Performance and Sizing: What are the sizing recommendations and what performance objectives and criteria do the design cater to? The answer may not be always simple and may require a few iterations. However, the point is to have at least some level of guidance and tweak it based on learnings.
• Security: Although other sections may touch upon it, it is important to make this section and address any specific security measures implemented in the application. This could be the use of secured protocols, network configurations, even some operational aspects like regular scanning and detection. This is not an operational document but should give guidance to the Operations team so that they know what measures they should have in place to secure the application.
• Enterprise Readiness: This covers various other aspects like high availability, accessibility, etc.
• Install and Upgrade: This section should cover considerations for fresh installation and upgrades. It is worth including any specific design considerations, such as the backward compatibility of the data model.
• Revision History: Finally, a section that contains the timestamp, the change author and a quick comment describing the change.

The following are some not so commonly used sections. But, I like to use these in my SDDs as this helps bring in a lot more clarity and enabling various teams (including the support teams).

• Developer Notes: This section contains useful tips and information on the code-level information. For example, how multi-threading should be used for a specific component, use of tokens to identify a request end-to-end, etc.
• Logging: Include specific patterns for details like understanding the flow, identifying a request, etc. Sample log snippets also can be extremely helpful.
• Troubleshooting: Provide information on how to troubleshoot the application. This should cover things like log locations, how to analyze logs, other system parameters to analyze, etc. If you can take a few key scenarios, that can also be helpful.
• Common Problems and Solutions: This is useful to capture the commonly observed issues and provide guidance on how to resolve them. As you can imagine, sections like these will continue to grow and can provide extremely useful information for the support knowledgebase.

There are a lot of areas to cover and not everything needs to be done on day one. However, having place holder sections and updating these over time can help you in building useful documentation.

Handling Future Updates To Documentation

Keeping documentation up-to-date is critical to ensure it continues to be an effective tool. Good checkpoints when you can ensure that the documentation is updated.

• Any important technical assumptions are introduced or changed
• Agile iteration boundaries
• When new features are developed
• When new major release begins

Conclusion

As we can see from this post, technical or internal documentation can be a quite effective tool in building quality software and keeping teams in sync. Hence, instead of looking at it as an overhead, look at it as an investment that will pay you off as you embark on your software journey.

Happy developing!
– Nitin

The post How To Approach The Internal Documentation Of Your Software Projects? appeared first on Cloud Nine Apps.

AWS CloudWatch offers centralized logging, monitoring, and analysis to make the developer’s job easier. A question that comes up for the Enterprise Applications that follow a hybrid cloud deployment (that is, one or more of the application components reside on-premise) is how can we use CloudWatch logs for the on-premise components? Is it even possible? The short answer is yes. And, we will see in this post how to do that.

Why Use CloudWatch For On-Premise Components?

There are several benefits of using CloudWatch for On-Premise components.

• Leverage from centralized logging: You can use the same capabilities for storing the logs centrally for the on-premise components that you are using for the rest of your Cloud-based components.
• Time Conversion: CloudWatch logs are stored in UTC. So, you do not have to worry about tedious conversions, which could often take up your precious time when analyzing logs across several components, especially if these are spread across geographically.
• Consistent Analysis: You can use the same tools and techniques that you are using for Cloud-based components.
• Avoid issues like logs rollover or difficult to access logs. Often, on-premise components are managed by customers or other clients that may require some coordination and effort.

How To Publish To CloudWatch Logs From On-Premise Components?

There are a couple of approaches to accomplish this.

1. Using the AWS CloudWatch Agent to publish logs: This can be extremely useful for on-premise components that follow an appliance model for deployment (such as a pre-baked image with the application components and dependencies). So, this approach is more configuration-centric and should not require code-level changes. Apart from log collection, the CloudWatch agent can also help in capturing system metrics (such as CPU and memory utilization).
2. Using the CloudWatch Logs API to publish logs: This approach requires enhancing the code to use the CloudWatch Logs API to publish logs. Of course, you can make it a reusable module or consider using a third-party library. But, the point is this is a code-centric approach that offers more flexibility.

In this post, we will be talking about using the CloudWatch Logs API. If you are interested in using the CloudWatch Agent, please refer to the AWS CloudWatch Agent documentation for details.

Using The CloudWatch Logs API To Publish Logs

The following code shows the CloudWatch Logs API usage.

package com.cloudnineapps.samples.aws;

import java.util.ArrayList;
import java.util.List;

import com.amazonaws.auth.AWSCredentialsProvider;
import com.amazonaws.auth.DefaultAWSCredentialsProviderChain;
import com.amazonaws.services.logs.AWSLogsClient;
import com.amazonaws.services.logs.AWSLogsClientBuilder;
import com.amazonaws.services.logs.model.CreateLogGroupRequest;
import com.amazonaws.services.logs.model.CreateLogStreamRequest;
import com.amazonaws.services.logs.model.DescribeLogGroupsRequest;
import com.amazonaws.services.logs.model.DescribeLogGroupsResult;
import com.amazonaws.services.logs.model.DescribeLogStreamsRequest;
import com.amazonaws.services.logs.model.DescribeLogStreamsResult;
import com.amazonaws.services.logs.model.InputLogEvent;
import com.amazonaws.services.logs.model.PutLogEventsRequest;
import com.amazonaws.services.logs.model.PutRetentionPolicyRequest;

/**
 * Sample client for AWS CloudWatch Logs API.
 */
public class AWSCloudWatchLogsSampleClient {

	/** The log group name. */
	private static final String LOG_GROUP = "/myapp/onprem/component-1";

	/** The log stream name. */
	private static final String LOG_STREAM = "app-log";
	
	/** The log retention period (in days). */
	private static final int LOG_RETENTION_PERIOD = 1;

	/** The AWS region. */
	private static String Region = "us-east-1";
	
	/** The CloudWatch client. */
	private static AWSLogsClient Client;
	
	
	/** Opens the CloudWatch log. */
	public static void openCloudWatchLog() throws Exception {
		AWSCredentialsProvider creds = new DefaultAWSCredentialsProviderChain();
		Client = (AWSLogsClient) AWSLogsClientBuilder.standard()
				     .withCredentials(creds)
				     .withRegion(Region)
				     .build();
		// Create and set up the log group if it doesn't exist
		DescribeLogGroupsRequest request = new DescribeLogGroupsRequest().withLogGroupNamePrefix(LOG_GROUP);
		DescribeLogGroupsResult result = Client.describeLogGroups(request);
		if (result.getLogGroups().isEmpty()) {
			CreateLogGroupRequest logGroupRequest = new CreateLogGroupRequest(LOG_GROUP);
			Client.createLogGroup(logGroupRequest);
			PutRetentionPolicyRequest policyRequest = new PutRetentionPolicyRequest(LOG_GROUP, LOG_RETENTION_PERIOD);
			Client.putRetentionPolicy(policyRequest);
			CreateLogStreamRequest logStreamRequest = new CreateLogStreamRequest(LOG_GROUP, LOG_STREAM);
			Client.createLogStream(logStreamRequest);
			log("Created the log group and the log stream.");
		}
	}
	
	/** Logs the specified message. */
	public static void log(String msg) throws Exception {
		// Retrieve the sequence token in the log stream
		DescribeLogStreamsRequest request = new DescribeLogStreamsRequest().withLogGroupName(LOG_GROUP).withLogStreamNamePrefix(LOG_STREAM);
		DescribeLogStreamsResult result = Client.describeLogStreams(request);
		String seqToken = result.getLogStreams().get(0).getUploadSequenceToken();

		// Write to the log stream
		List<InputLogEvent> logEvents = new ArrayList<InputLogEvent>();
		InputLogEvent logEvent = new InputLogEvent().withMessage(msg).withTimestamp(System.currentTimeMillis());
		logEvents.add(logEvent);
		PutLogEventsRequest logRequest = new PutLogEventsRequest(LOG_GROUP, LOG_STREAM, logEvents).withSequenceToken(seqToken);
		Client.putLogEvents(logRequest);
	}
		
	/** Main */
	public static void main(String[] args) throws Exception {
		System.out.println("Launching the application...");
		openCloudWatchLog();
		// Sample log statements
		log("Starting the app...");
		log("Another message");
		System.out.println("Execution completed.");
	}
}

Let’s walk through the code. You can check out the Resources section for the complete code (including the maven pom that can be used to compile and execute).

• The main() method invokes the openCloudWatchLog() method to initialize the CloudWatch Logs SDK client.
• The openCloudWatchLog() method checks if the required Log Group (/myapp/onprem/component-1) exists using the DescribeLogGroupsRequest and the Client.describeLogGroups() call. If not, it creates the Log Group using the CreateLogGroupRequest and the Client.createLogGroup() call. We should always ensure that an appropriate log retention period is set on the log group to avoid accruing a huge log that can lead to a high cost. This is accomplished using the PutRetentionPolicyRequest and the Client.putRetentionPolicy() call. Then, we create the Log Stream using the CreateLogStreamRequest and the Client.createLogStream() call. The following screenshot shows the Log Group in the CloudWatch Console.
  
• Here is a screenshot of the Log Stream under the Log Group.
  
• Next, the code uses the log() method to log sample messages. It uses DescribeLogStreamsRequest and the Client.describeLogStreams() call to retrieve the Log Stream and fetch the upload sequence token. This token must be included when publishing logs (except for the very first publish). Then, we are creating an InputLogEvent with the supplied message and timestamp. The log is published using the PutLogEventsRequest and the Client.putLogEvents() call. As you might have noticed, you do not have to publish individual log statements. You could very well add multiple InputLogEvent objects to publish a batch of logs. The following screenshot demonstrates a sample run of the code.
  

Using IAM Policy To Restrict Access To Specific Log

As part of such a setup, it is important to use restrictive access so that the on-premise component can only access the specific log. The good thing is you can enforce this using IAM as follows.

• Create one or more IAM users for the on-premise components. Grant these users programmatic access only.
• Create a custom policy (or assign an inline policy) like the one shown below and assign it to the above IAM user(s).

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "CloudWatchLogGroupQueryAccess",
            "Effect": "Allow",
            "Action": [
                "logs:DescribeLogGroups"
            ],
            "Resource": "arn:aws:logs:*:*:*"
        },
        {
            "Sid": "CloudWatchLogsAccess",
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:PutRetentionPolicy",
                "logs:DescribeLogStreams",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": "arn:aws:logs:*:*:log-group:/myapp/onprem/*:log-stream:*"
        }
    ]
}

This policy grants access to the required CloudWatch Logs API calls on the on-premise logs only.

Best Practices For Publishing Logs From On-Premise Components

The following are some key best practices to consider.

• Logging can easily get very network intensive. Hence, be quite judicious about which logs are sent to CloudWatch logs. For example, ERROR and WARNING logs are good candidates, but DEBUG is not typically.
• Avoid logging any sensitive data. This is critical, and often not as well thought. For example, some of the things to avoid are logging passwords in plain text, users’ Personally Identifiable Information (PII), and so on.
• Always set an appropriate log retention period on the Log Group.
• Use a well-defined naming convention for the Log Group and Log Streams. For example, /myapp/onprem/component-1.
• Use a restrictive IAM policy for the user that is used to publish logs, and ensure it has access to the component-specific logs only.
• Prefer using application-specific IAM user(s) for logging across multiple applications. This way, you can track and manage access better.

Conclusion

When designing hybrid cloud or on-premise components, evaluate publishing logs to CloudWatch. By following a few key best practices to ensure this is done in a manner that meets the application needs as well as enterprise readiness considerations like security and performance, this can be quite helpful in pro-active application monitoring and management.

Resources

• AWSCloudWatchLogsSampleClient GitHub Repository

Happy logging!
– Nitin

If you liked this post, you will find my AWS Advanced For Developers course helpful that focuses on many such best practices and techniques to design and deploy real-world applications in AWS.

The post How To Use AWS CloudWatch With On-Premise Application Components? appeared first on Cloud Nine Apps.

AWS CloudFormation (CFN) makes it easy to deploy and manage your application infrastructure as an atomic unit using CloudFormation templates. In this article, we will cover how to use CFN to create a multi-tier stack. We will also see how to handle different deployment variations, such as a full-blown production stack with a load balancer, and a smaller footprint development stack using the same CFN template! Lastly, I will also highlight some important tips when designing the CFN templates for your applications.

Note: If you are new to CloudFormation, I highly recommend reading the AWS CloudFormation – An Architect’s Best Friend first to familiarize yourself with the basics.

Identify The Application Deployment Models

Before you start designing the CFN template, it is important to understand in which all possible ways the application can be deployed. At a minimum, identify the key deployment models. For example, what would a typical development deployment look like? Which resources would be needed and what are their configurations? Likewise, for production. Having these details upfront has several benefits.

• You will have a clear understanding of the legitimate combinations in which the application can be deployed.
• You can then delve into the resource configurations and addressing other key aspects like security.
• Lastly, you can ensure that the deployment models are as cost-optimal as possible. For example, the development stack may have the smallest footprint possible to keep cost low versus the production stack that may have a larger footprint.

Let’s take a look at our sample multi-tier stack.

• For the sake of discussion, we will cover 2 deployment models: Development and Production.
• The Production deployment will comprise of a public-facing load balancer, which will be backed by 2 web-tier EC2 instances running Apache. These instances will talk to the EC2 instance hosting the app-tier running tomcat.
• Security Groups will be used for access control. The PublicWebSecurityGroup will be assigned to the web-tier and the AppSecurityGroup will be assigned to the app-tier. Now, you may have noticed the PrivateWebSecurityGroup. Can you guess what’s that for? Perhaps you got it. It is the Security Group created for the Production stack to ensure that the web-tier EC2 instances are only accessible via the load balancer and not exposed publicly.
• The Development deployment of the stack will comprise of a single web-tier EC2 instance and a single app-tier EC2 instance.

So, as you can see, this seemingly simple stack deployment can also become complex considering the different deployment models. But, not to worry. CFN provides us several useful capabilities to make this work.

The Multi-Tier Stack CFN Template

Here is the CFN template.

{
  "AWSTemplateFormatVersion": "2010-09-09",
  "Description": "A multi-tier stack instance.",
  "Parameters": {
    "DeploymentType": {
      "Description": "The deployment type.",
      "Type": "String",
      "AllowedValues": ["Development", "Production"],
      "Default": "Development"
    },
    "VPC": {
      "Description": "The VPC for the EC2 instances.",
      "Type": "AWS::EC2::VPC::Id"
    },
    "Subnet1": {
      "Description": "The subnet1 for the EC2 instances.",
      "Type": "AWS::EC2::Subnet::Id"
    },
    "Subnet2": {
      "Description": "The subnet2 for the EC2 instances.",
      "Type": "AWS::EC2::Subnet::Id"
    },
    "SSHSecurityGroup": {
      "Description": "The SSH Security Group for the EC2 instances.",
      "Type": "AWS::EC2::SecurityGroup::Id"
    },
    "KeyPair": {
      "Description": "The key pair name to use to connect to the EC2 instances.",
      "Type": "String"
    }
  },
  "Mappings": {
    "Globals": {
      "Constants": {
        "ImageId": "ami-0b898040803850657",
        "AssignPublicIP": "true",
        "WebInstanceSuffix": "web",
        "AppInstanceSuffix": "app"
      }
    },
    "DeploymentTypes": {
      "Development": {
        "InstanceType": "t2.small",
        "StorageSize": "20"
      },
      "Production": {
        "InstanceType": "t2.medium",
        "StorageSize": "50"
      }
    }
  },
  "Conditions": {
    "CreateMultipleInstances": {"Fn::Not": [{"Fn::Equals": ["Development", {"Ref": "DeploymentType"}]}]}
  },
  "Resources": {
    "LoadBalancer": {
      "Type": "AWS::ElasticLoadBalancing::LoadBalancer",
      "Condition": "CreateMultipleInstances",
      "Properties": {
        "Instances": [{"Ref": "Web1EC2Instance"}, {"Ref": "Web2EC2Instance"}],
        "Subnets": [{"Ref": "Subnet1"}, {"Ref": "Subnet2"}],
        "SecurityGroups": [{"Ref": "PublicWebSecurityGroup"}],
        "Listeners": [{
          "LoadBalancerPort": 80,
          "InstancePort": 80,
          "Protocol": "HTTP"
        }],
        "HealthCheck": {
          "Target": "HTTP:80/",
          "HealthyThreshold": "3",
          "UnhealthyThreshold": "5",
          "Interval": "10",
          "Timeout": "3"
        }
      },
      "Metadata": {
        "AWS::CloudFormation::Designer": {
          "id": "fbf8f065-5dc7-4850-bb4f-8c4287a8cb7b"
        }
      }
    },
    "Web1EC2Instance": {
      "Type": "AWS::EC2::Instance",
      "Properties": {
        "ImageId": {"Fn::FindInMap": ["Globals", "Constants", "ImageId"]},
        "InstanceType": {"Fn::FindInMap": ["DeploymentTypes", {"Ref": "DeploymentType"}, "InstanceType"]},
        "NetworkInterfaces": [{
          "DeviceIndex": "0",
          "SubnetId": {"Ref": "Subnet1"},
          "AssociatePublicIpAddress": {"Fn::FindInMap": ["Globals", "Constants", "AssignPublicIP"]},
          "GroupSet": [{"Ref": "SSHSecurityGroup"}, {"Fn::If": ["CreateMultipleInstances", {"Ref": "PrivateWebSecurityGroup"}, {"Ref": "PublicWebSecurityGroup"}]}]
        }],
        "BlockDeviceMappings": [{
          "DeviceName": "/dev/sdm",
          "Ebs": {
            "VolumeType": "gp2",
            "VolumeSize": {"Fn::FindInMap": ["DeploymentTypes", {"Ref": "DeploymentType"}, "StorageSize"]},
            "DeleteOnTermination": "true"
          }
        }],
        "KeyName": {"Ref": "KeyPair"},
        "Tags": [{"Key": "Name", "Value": {"Fn::Join": ["-", [{"Ref": "AWS::StackName"}, {"Fn::FindInMap": ["Globals", "Constants", "WebInstanceSuffix"]}, "1"]]}}],
        "UserData": {"Fn::Base64": {"Fn::Join": ["", [
          "#!/bin/bash\n",
          "yum install -y aws-cfn-bootstrap\n",
          "\n",
          "# Install the software\n",
          "/opt/aws/bin/cfn-init -v",
          " --stack ", {"Ref": "AWS::StackName"},
          " --resource Web1EC2Instance",
          " --configsets Install",
          " --region ", {"Ref": "AWS::Region"}, "\n",
          "\n",
          "# Signal resource creation completion\n",
          "/opt/aws/bin/cfn-signal -e $?",
          " --stack ", {"Ref": "AWS::StackName"},
          " --resource Web1EC2Instance",
          " --region ", {"Ref": "AWS::Region"}, "\n"
        ]]}}
      },
      "CreationPolicy": {
        "ResourceSignal": {
          "Count": 1,
          "Timeout": "PT5M"
        }
      },
      "DependsOn": "AppEC2Instance",
      "Metadata": {
        "AWS::CloudFormation::Designer": {
          "id": "83fb66e0-bfdf-4076-9d59-3f1077f47a2a"
        },
        "AWS::CloudFormation::Init": {
          "configSets": {
            "Install": ["Install"]
          },
          "Install": {
            "packages": {
              "yum": {
                "httpd": []
              }
            },
            "files": {
              "/var/www/html/index.html": {
                "content": {"Fn::Join": ["", [
                  "<html>\n",
                  "  <head>\n",
                  "    <title>Welcome to a sample multi-tier app!</title>\n",
                  "  </head>\n",
                  "  <body>\n",
                  "    <h1>Welcome to a sample multi-tier app!</h1>\n",
                  "  </body>\n",
                  "</html>\n"
                ]]},
                "mode": "0600",
                "owner": "apache",
                "group": "apache"
              }
            },
            "services": {
              "sysvinit": {
                "httpd": {"enabled": "true", "ensureRunning": "true"}
              }
            }
          }
        }
      }
    },
    "Web2EC2Instance": {
      "Type": "AWS::EC2::Instance",
      "Condition": "CreateMultipleInstances",
      "Properties": {
        "ImageId": {"Fn::FindInMap": ["Globals", "Constants", "ImageId"]},
        "InstanceType": {"Fn::FindInMap": ["DeploymentTypes", {"Ref": "DeploymentType"}, "InstanceType"]},
        "NetworkInterfaces": [{
          "DeviceIndex": "0",
          "SubnetId": {"Ref": "Subnet2"},
          "AssociatePublicIpAddress": {"Fn::FindInMap": ["Globals", "Constants", "AssignPublicIP"]},
          "GroupSet": [{"Ref": "SSHSecurityGroup"}, {"Ref": "PrivateWebSecurityGroup"}]
        }],
        "BlockDeviceMappings": [{
          "DeviceName": "/dev/sdm",
          "Ebs": {
            "VolumeType": "gp2",
            "VolumeSize": {"Fn::FindInMap": ["DeploymentTypes", {"Ref": "DeploymentType"}, "StorageSize"]},
            "DeleteOnTermination": "true"
          }
        }],
        "KeyName": {"Ref": "KeyPair"},
        "Tags": [{"Key": "Name", "Value": {"Fn::Join": ["-", [{"Ref": "AWS::StackName"}, {"Fn::FindInMap": ["Globals", "Constants", "WebInstanceSuffix"]}, "2"]]}}],
        "UserData": {"Fn::Base64": {"Fn::Join": ["", [
          "#!/bin/bash\n",
          "yum install -y aws-cfn-bootstrap\n",
          "\n",
          "# Install the software\n",
          "/opt/aws/bin/cfn-init -v",
          " --stack ", {"Ref": "AWS::StackName"},
          " --resource Web2EC2Instance",
          " --configsets Install",
          " --region ", {"Ref": "AWS::Region"}, "\n",
          "\n",
          "# Signal resource creation completion\n",
          "/opt/aws/bin/cfn-signal -e $?",
          " --stack ", {"Ref": "AWS::StackName"},
          " --resource Web2EC2Instance",
          " --region ", {"Ref": "AWS::Region"}, "\n"
        ]]}}
      },
      "CreationPolicy": {
        "ResourceSignal": {
          "Count": 1,
          "Timeout": "PT5M"
        }
      },
      "DependsOn": "AppEC2Instance",
      "Metadata": {
        "AWS::CloudFormation::Designer": {
          "id": "4e1f2401-833d-442d-be04-89fac2d74778"
        },
        "AWS::CloudFormation::Init": {
          "configSets": {
            "Install": ["Install"]
          },
          "Install": {
            "packages": {
              "yum": {
                "httpd": []
              }
            },
            "files": {
              "/var/www/html/index.html": {
                "content": {"Fn::Join": ["", [
                  "<html>\n",
                  "  <head>\n",
                  "    <title>Welcome to a sample multi-tier app!</title>\n",
                  "  </head>\n",
                  "  <body>\n",
                  "    <h1>Welcome to a sample multi-tier app!</h1>\n",
                  "  </body>\n",
                  "</html>\n"
                ]]},
                "mode": "0600",
                "owner": "apache",
                "group": "apache"
              }
            },
            "services": {
              "sysvinit": {
                "httpd": {"enabled": "true", "ensureRunning": "true"}
              }
            }
          }
        }
      }
    },
    "AppEC2Instance": {
      "Type": "AWS::EC2::Instance",
      "Properties": {
        "ImageId": {"Fn::FindInMap": ["Globals", "Constants", "ImageId"]},
        "InstanceType": {"Fn::FindInMap": ["DeploymentTypes", {"Ref": "DeploymentType"}, "InstanceType"]},
        "NetworkInterfaces": [{
          "DeviceIndex": "0",
          "SubnetId": {"Ref": "Subnet1"},
          "AssociatePublicIpAddress": {"Fn::FindInMap": ["Globals", "Constants", "AssignPublicIP"]},
          "GroupSet": [{"Ref": "SSHSecurityGroup"}, {"Ref": "AppSecurityGroup"}]
        }],
        "BlockDeviceMappings": [{
          "DeviceName": "/dev/sdm",
          "Ebs": {
            "VolumeType": "gp2",
            "VolumeSize": {"Fn::FindInMap": ["DeploymentTypes", {"Ref": "DeploymentType"}, "StorageSize"]},
            "DeleteOnTermination": "true"
          }
        }],
        "KeyName": {"Ref": "KeyPair"},
        "Tags": [{"Key": "Name", "Value": {"Fn::Join": ["-", [{"Ref": "AWS::StackName"}, {"Fn::FindInMap": ["Globals", "Constants", "AppInstanceSuffix"]}, "1"]]}}],
        "UserData": {"Fn::Base64": {"Fn::Join": ["", [
          "#!/bin/bash\n",
          "yum install -y aws-cfn-bootstrap\n",
          "\n",
          "# Install the software\n",
          "/opt/aws/bin/cfn-init -v",
          " --stack ", {"Ref": "AWS::StackName"},
          " --resource AppEC2Instance",
          " --configsets Install",
          " --region ", {"Ref": "AWS::Region"}, "\n",
          "\n",
          "# Signal resource creation completion\n",
          "/opt/aws/bin/cfn-signal -e $?",
          " --stack ", {"Ref": "AWS::StackName"},
          " --resource AppEC2Instance",
          " --region ", {"Ref": "AWS::Region"}, "\n"
        ]]}}
      },
      "CreationPolicy": {
        "ResourceSignal": {
          "Count": 1,
          "Timeout": "PT5M"
        }
      },
      "Metadata": {
        "AWS::CloudFormation::Designer": {
          "id": "4720705c-1add-4c63-abd6-d9fd4626a43d"
        },
        "AWS::CloudFormation::Init": {
          "configSets": {
            "Install": ["Install"]
          },
          "Install": {
            "packages": {
              "yum": {
                "tomcat": [],
                "tomcat-webapps": []
              }
            },
            "services": {
              "sysvinit": {
                "tomcat": {"enabled": "true", "ensureRunning": "true"}
              }
            }
          }
        }
      }
    },
    "PublicWebSecurityGroup": {
      "Type": "AWS::EC2::SecurityGroup",
      "Properties": {
        "GroupName": {"Fn::Join": ["-", [{"Ref": "AWS::StackName"}, "public-web-sg"]]},
        "GroupDescription": {"Fn::Join": ["", ["Enables public web access for ", {"Ref": "AWS::StackName"}, "."]]},
        "VpcId": {"Ref": "VPC"},
        "SecurityGroupIngress": [
          {"IpProtocol": "tcp", "FromPort": "80", "ToPort": "80", "CidrIp": "0.0.0.0/0"}
        ],
        "Tags": [{"Key": "Name", "Value": {"Fn::Join": ["-", [{"Ref": "AWS::StackName"}, "public-web-sg"]]}}]
      },
      "Metadata": {
        "AWS::CloudFormation::Designer": {
          "id": "bfef096b-3b53-4799-b880-0df21011e7ed"
        }
      }
    },
    "PrivateWebSecurityGroup": {
      "Type": "AWS::EC2::SecurityGroup",
      "Properties": {
        "GroupName": {"Fn::Join": ["-", [{"Ref": "AWS::StackName"}, "private-web-sg"]]},
        "GroupDescription": {"Fn::Join": ["", ["Enables private web access for ", {"Ref": "AWS::StackName"}, "."]]},
        "VpcId": {"Ref": "VPC"},
        "SecurityGroupIngress": [
          {"IpProtocol": "tcp", "FromPort": "80", "ToPort": "80", "SourceSecurityGroupId": {"Ref": "PublicWebSecurityGroup"}}
        ],
        "Tags": [{"Key": "Name", "Value": {"Fn::Join": ["-", [{"Ref": "AWS::StackName"}, "private-web-sg"]]}}]
      },
      "Metadata": {
        "AWS::CloudFormation::Designer": {
          "id": "f00bae41-3fe2-41c1-ad14-64680744f71f"
        }
      }
    },
    "AppSecurityGroup": {
      "Type": "AWS::EC2::SecurityGroup",
      "Properties": {
        "GroupName": {"Fn::Join": ["-", [{"Ref": "AWS::StackName"}, "app-sg"]]},
        "GroupDescription": {"Fn::Join": ["", ["Enables access to ", {"Ref": "AWS::StackName"}, " app tier."]]},
        "VpcId": {"Ref": "VPC"},
        "SecurityGroupIngress": [
          {"IpProtocol": "tcp", "FromPort": "8080", "ToPort": "8080", "SourceSecurityGroupId": {"Fn::If": ["CreateMultipleInstances", {"Ref": "PrivateWebSecurityGroup"}, {"Ref": "PublicWebSecurityGroup"}]}}
        ],
        "Tags": [{"Key": "Name", "Value": {"Fn::Join": ["-", [{"Ref": "AWS::StackName"}, "app-sg"]]}}]
      },
      "Metadata": {
        "AWS::CloudFormation::Designer": {
          "id": "adf9b8b7-25c4-4ddb-9401-e5c34da55511"
        }
      }
    }
  },
  "Outputs": {
    "StackURL": {
      "Description": "The stack web URL.",
      "Value": {"Fn::Join": ["", ["http://",
          {"Fn::If": ["CreateMultipleInstances", {"Fn::GetAtt": ["LoadBalancer", "DNSName"]}, {"Fn::GetAtt": ["Web1EC2Instance", "PublicIp"]}]}
      ]]}
    }
  },
  "Metadata": {
    "AWS::CloudFormation::Designer": {
      "fbf8f065-5dc7-4850-bb4f-8c4287a8cb7b": {
        "size": {
          "width": 60,
          "height": 60
        },
        "position": {
          "x": 560,
          "y": 50
        },
        "z": 0,
        "embeds": [],
        "isassociatedwith": [
          "83fb66e0-bfdf-4076-9d59-3f1077f47a2a",
          "4e1f2401-833d-442d-be04-89fac2d74778",
          "bfef096b-3b53-4799-b880-0df21011e7ed"
        ]
      },
      "83fb66e0-bfdf-4076-9d59-3f1077f47a2a": {
        "size": {
          "width": 60,
          "height": 60
        },
        "position": {
          "x": 470,
          "y": 150
        },
        "z": 0,
        "embeds": []
      },
      "4e1f2401-833d-442d-be04-89fac2d74778": {
        "size": {
          "width": 60,
          "height": 60
        },
        "position": {
          "x": 650,
          "y": 150
        },
        "z": 0,
        "embeds": []
      },
      "bfef096b-3b53-4799-b880-0df21011e7ed": {
        "size": {
          "width": 60,
          "height": 60
        },
        "position": {
          "x": 460,
          "y": 50
        },
        "z": 0,
        "embeds": []
      },
      "c4db756b-b07b-4324-be5f-6ed116047ed8": {
        "source": {
          "id": "fbf8f065-5dc7-4850-bb4f-8c4287a8cb7b"
        },
        "target": {
          "id": "bfef096b-3b53-4799-b880-0df21011e7ed"
        },
        "z": 11
      },
      "4720705c-1add-4c63-abd6-d9fd4626a43d": {
        "size": {
          "width": 60,
          "height": 60
        },
        "position": {
          "x": 553,
          "y": 265
        },
        "z": 0,
        "embeds": []
      },
      "a60d3d35-5a1d-4a58-a2bd-6f5ffe94017a": {
        "source": {
          "id": "83fb66e0-bfdf-4076-9d59-3f1077f47a2a"
        },
        "target": {
          "id": "4720705c-1add-4c63-abd6-d9fd4626a43d"
        },
        "z": 11
      },
      "f00bae41-3fe2-41c1-ad14-64680744f71f": {
        "size": {
          "width": 60,
          "height": 60
        },
        "position": {
          "x": 660,
          "y": 270
        },
        "z": 1,
        "embeds": []
      },
      "adf9b8b7-25c4-4ddb-9401-e5c34da55511": {
        "size": {
          "width": 60,
          "height": 60
        },
        "position": {
          "x": 540,
          "y": 360
        },
        "z": 1,
        "embeds": []
      },
      "5f28f4f3-edee-437e-856b-dda339912a82": {
        "source": {
          "id": "4720705c-1add-4c63-abd6-d9fd4626a43d"
        },
        "target": {
          "id": "adf9b8b7-25c4-4ddb-9401-e5c34da55511"
        },
        "z": 11
      }
    }
  }
}

Let’s break it down by section to understand it better.

Template Parameters

• The DeploymentType parameter is used to determine the deployment model. Such logical parameters are extremely useful as compared to exposing the individual resource properties as parameters. Why? Firstly, these enable the CFN template designer to ensure that the deployments meet only the prescribed models. Secondly, these hide unnecessary complexities from the template users. Also, tomorrow if you add more resources or change configurations, the template users do not have to be bothered about these.
• The next 3 parameters take the target VPC and subnet information. Note that because we are doing a Production deployment we do want to leverage from the high availability capabilities offered by AWS so that we can distribute our EC2 instances across multiple Availability Zones.
• The SSHSecurityGroup parameter is used to specify the Security Group that will be used to connect to the EC2 instances. Now, you could very well create a Security Group for SSH in this template itself. However, I wanted to demonstrate the use of a Security Group that has been created by the networking team for access control. For example, they may set up the SSH Security Group to only allow inbound traffic from the corporate network. So, as opposed to every application team coming up with their own SSH Security Group, here the organization has chosen to use the same SSH Security Group for consistency and ease of management. These considerations are quite important when you design CFN templates. You want to ensure you are not creating backdoors that could lead to a potential security breach.
• The KeyPair parameter specifies the SSH key pair name that will be used for connecting to the EC2 instances.

Mappings

• The Globals map defines constants to avoid hardcoding values all over the template. For example, instead of hardcoding the AMI ID everywhere, we can simply define it once here. Tomorrow, if we want to change it, we just have to update it in one place. Likewise, the other constants.
• The DeploymentTypes map specifies the resource properties for each deployment model. For example, a Development EC2 instance will use t2.small instance type. Whereas, a Production EC2 instance will use t2.medium.

Conditions

• The CreateMultipleInstances condition is set to true only if it is NOT a Development deployment. This will be used later in the template when creating the resources. If you are wondering why I didn’t call it IsProductionDeployment, there is a good reason. What if I add another deployment model tomorrow called QA, which also has multiple instances? By keeping the condition name more generic, we can use it for both these deployment models.

Resources

Notice the use of DependsOn to ensure the resources are created in the correct order.

• First, it creates a load balancer (LB) for the web-tier if the CreateMultipleInstances condition is true. This LB will have 2 EC2 instances attached – Web1EC2Instance and Web2EC2Instance. It will have access to the specified subnets and will be assigned the PublicWebSecurityGroup. The LB will listen on port 80 (HTTP) and will forward traffic to port 80 on the EC2 instances. As we know, LB works by checking the health of the underlying instances. In this case, it will access the base URL (/) every 10 seconds with a timeout value of 3 seconds. If the health check fails 5 consecutive times, the instance will be declared unhealthy. And, the check must succeed 3 consecutive times to declare the instance as healthy.
• Next, it creates the Web1EC2Instance. It uses the Globals map to find some property values like the AMI ID. The InstanceType is set based on the DeploymentType. If it is a Production EC2 instance, it will be assigned the PrivateWebSecurityGroup to avoid direct public access. For Development, it will be assigned the PublicWebSecurityGroup. Also, the SSH Security Group will be assigned. The instance will have a single EBS volume attached. Apart from KeyName and Tags, notice the use of UserData. This is used to install and configure the apache daemon when the instance first boots using the AWS CFN Helper Scripts. The Metadata section contains the information used by these scripts to do their work. The CreationPolicy is used to ensure that CFN waits till it receives a success or failure signal from the UserData script with a timeout of 5 minutes. Note that Web1EC2Instance is created regardless of the DeploymentType since the stack will have at least one web-tier instance.
• The Web2EC2Instance is created only if the CreateMultipleInstances condition is set to true. Its configuration is the same as the Web1EC2Instance.
• The AppEC2Instance is created similarly with the key difference being it will be assigned the AppSecurityGroup and tomcat will be installed on it. Note that just like the web-tier we could create multiple EC2 instances for the app-tier and put an LB in-front of these for high availability and load balancing purposes. But, I’ve skipped that part here for brevity purposes.
• Next, it creates the Security Groups for the respective tiers. Notice how the PrivateWebSecurityGroup sets its ingress rule to permit traffic only from the source resource that has the PublicWebSecurityGroup assigned. This will ensure that only the LB can talk to the web EC2 instances.

Outputs

• The template outputs the stack access URL. Again, it uses the CreateMultipleInstances condition to determine whether the output URL should be based on the load balancer or the Web1EC2Instance.

Metadata

This section contains data used by the CFN Designer tool.

Sample Deployment Commands

The following command shows a Production deployment.

aws cloudformation deploy --profile aws-training --stack-name MyAppProdStack --parameter-overrides DeploymentType=Production VPC=vpc-0ef286bd199748f2a Subnet1=subnet-05eaf962fd4e0e12c Subnet2=subnet-00077ede2ac0521a6 SSHSecurityGroup=sg-0fa7434cec1fd0b2d KeyPair=C9SSHKeyPair --template-file cfns/Multi_Tier_Stack.json

And, here’s a command that shows a Development deployment.

aws cloudformation deploy --profile aws-training --stack-name MyAppDevStack --parameter-overrides DeploymentType=Development VPC=vpc-0ef286bd199748f2a Subnet1=subnet-05eaf962fd4e0e12c Subnet2=subnet-00077ede2ac0521a6 SSHSecurityGroup=sg-0fa7434cec1fd0b2d KeyPair=C9SSHKeyPair --template-file cfns/Multi_Tier_Stack.json

Conclusion

Great job in reading along. As you might have already gathered, authoring a good CFN template is no different from writing good code. It needs to have considerations of what you are trying to accomplish, enterprise readiness aspects like security and be cost-efficient. By thinking about these points upfront you can not only design a better template but also avoid common issues and save time in the longer run.

Happy deploying!
– Nitin

The post How To Create A Multi-Tier Stack Using AWS CloudFormation appeared first on Cloud Nine Apps.

AWS CloudFormation (CFN) helps in automating deployments by delivering Infrastructure as a Code (IaaC). It offers several useful capabilities, like simple templates, support for a wide range of AWS services, dependency management, parallel deployments, and so on. To use CloudFormation, you create CFN templates either from scratch or from samples. You can also use tools like the CloudFormation Designer to author the CFN templates. However, similarly to coding, you will run into errors with CFN as well. In this post, we will cover the two prominent types of CFN errors and how to troubleshoot these.

Types of CloudFormation Errors

There are two types of CFN errors.

1. Syntax Errors: A CFN template is a text document in either JSON or YAML format. The syntax errors in the CFN template lead to this error. For example, a missing comma or brace in JSON, an incorrect indentation in YAML, and so on. Such a template is not even deployed as the CloudFormation Console or the CLI will fail upon detecting the error.
2. Semantic Errors: These occur at deployment time typically due to coding or an infrastructure issue. For example, an incorrectly specified resource property name, trying to create a duplicate resource, and so on.

How To Troubleshoot CloudFormation Syntax Errors?

Let’s take an example here. The following screenshot shows a CFN template snippet in JSON format.

As you can see, the curly brace for the PolicyDocument property is missing. When we try to deploy this CFN template, we will see an error like the one shown below.

Here the JSON parser has detected a missing comma or a curly brace. After you add the missing brace, the error will be resolved. Errors like these are quite common during development. Here are some tips on how to resolve or minimize the occurrence of such errors.

• Check if your text editor supports block matching capabilities, like the powerful VI editor. This can be used to find the matching brace, and if you find that it is not on the expected element you have found the problem area. Then you can keep drilling down till you find the problem. As a general practice, it is also a good idea to always specify the closing brace when opening a brace so that you do not miss it. This can really come in handy for large templates.
• You can also use a JSON validator or beautifier. There are several available online. While in most cases the validator may not reveal any more useful information than what the CFN CLI output shows, the beautifier may be a bit helpful to visually inspect the template for any anomalies.

How To Troubleshoot CloudFormation Semantic Errors?

The semantic errors can range from simple things like incorrect property names, missing resource names to infrastructure-related errors, such as duplicate infrastructure resource name. And, as we discussed earlier, these occur at the deployment time. So, it may increase your end-to-end resolution time. Let’s take the example wherein we are trying to deploy an S3 bucket using a CFN template but a bucket with the specified name already exists. The following screenshot shows the CFN CLI output.

As you can see, the CLI execution failed. However, unlike the syntax error, the details are not available in this output. So, to troubleshoot further, you can either go to the CloudFormation Console or run the command shown in the above output.

aws cloudformation describe-stack-events –stack-name c9apps-demo-bucket1

This will show the stack events in reverse chronological order (most recent event first). Scroll through the list till you find the error cause as shown below.

It shows that a bucket named c9apps-demo-bucket (which was the bucket name we specified when deploying the template) already exists in another stack. This approach can be particularly useful for DevOps pipelines to retrieve the error information.

The other option is to go to the CloudFormation Console and look into the stack events for the error cause as shown below.

As we can see, the console shows the same information.

While semantic errors is a broader category and it is difficult to have a silver bullet solution for every scenario, here are some general tips.

• Use the AWS Resource and Property Types Reference document to check the resources types and properties.
• Use unique resource identifier names in the CFN templates. In general, giving names based on purpose is a good idea. For example, instead of calling it EC2Instance1, a better name would be WebTierInstance1.
• CloudFormation offers several Intrinsic Functions for common computing needs. Leverage from these to make more meaningful and unique resource names. For example, the Fn::Join Intrinsic Function can be used to combine a list of strings.
• Leverage from the lifecycle for choosing the resource names. For example, resources that are global in nature (such as IAM role) may not have the stack name as part of their names. Whereas, resources that are meant for a specific stack only can use the stack name to make their names unique.

Troubleshooting CFN errors takes some practice. Also, at times the error messages may not be easy to understand. So, it is a good idea to familiarize yourself with these techniques so that you are better prepared when the issues occur.

Be a smart troubleshooter!
– Nitin

If you liked this post, you will find my AWS CloudFormation Deep Dive course helpful that focuses on many such best practices, techniques and hands-on examples to use CloudFormation in real-world deployments.

The post How To Troubleshoot AWS CloudFormation Errors appeared first on Cloud Nine Apps.

AWS CloudFormation (CFN) conditions are quite useful for purposes like conditionally create resources, conditionally set the resource properties, and so on. However, when you start getting into some advanced scenarios, these may become a bit limited. For example, checking for the existence of a resource so that you create it only once. How do you handle such scenarios? Is there any way you can do this via CFN as opposed to using some alternatives? That is precisely the purpose of this article.

Note that this is an advanced CFN topic. If you are new to CFN, please check out the AWS CloudFormation – An Architect’s Best Friend to understand the basics first.

What Does Creating A Dynamic Condition Expression Mean?

Simply put, it means creating the expression text dynamically at the deployment time. Typically, the condition expression is static. For example, take a look at the condition below that will evaluate to true if the CreateGlobalResourcesParam parameter is set to “true”.

  "CreateGlobalResources": {"Fn::Equals", ["true", {"Ref": "CreateGlobalResourcesParam"}]}

When creating a Dynamic Condition Expression, the expression text is prepared at the deployment time.

"CreateGlobalResources": <content to prepare the expression text dynamically>

What Is The Need To Create A Dynamic Condition Expression?

To understand the need, let’s take a simple use case. Let’s say you have a CFN template that creates a serverless stack. It comprises a lambda and associated resources. Since the user base is spread across the globe, the plan is to create a stack per target region. For this discussion, let’s use us-east-1 and us-west-1 AWS regions with us-east-1 being the primary region.

So far so good. Now, we know that lambda requires an execution IAM role so that it has access to the required AWS resources. And, there are going to be two lambda deployments (one per region). So, we have two options – either create a lambda role per stack or create a single IAM role (say, in the primary stack) that will be used by all subsequent stacks. Both options have their own merits. The former offers more autonomy to each stack, whereas the second option leverages from the lifecycle of resources and minimizes the sprawl of roles that serve the same purpose. Another advantage of the second option is if there were updates to the role, you only need to update the primary stack and all stacks will automatically get the updates, thus reducing the end-to-end rollout team. Also, there are limits to the number of IAM roles you can create. Although, you may be able to request an increase. This is just one scenario. But, there could be similar other use cases where you are trying to reuse a global resource across stacks.

So, for this discussion let’s say that we do want to create the IAM role only once. Now, let’s talk about how to achieve this by creating a Dynamic Condition Expression.

Using Macro To Create A Dynamic Condition Expression

CFN offers a powerful capability called Macro. If you have ever programmed in a language like C/C++ (or another language that supports pre-processors), you may be already familiar with the use of macros. Essentially, a CFN Macro lets you execute certain logic to modify either the content of the template or a snippet within the template. All macros are evaluated before executing the CFN template. So, these are perfect to inject the condition expression dynamically. The following screenshot demonstrates this.

Let’s understand this better.

• In the Conditions block, we are defining a condition named CreateGlobalResources. It should be set to true if the global resources should be created. Otherwise, it should be set to false.
• It is using the Fn::Transform intrinsic function to invoke the ResourceHelper macro with 2 parameters – Operation and RoleName. We will see the details of the macro later in this post. The Operation parameter specifies the operation to perform (in this case, roleExists, which will check for the existence of the specified role). The RoleName parameter specifies the name of the role to check.
• Here, the macro is expected to return the string “true” only if the role exists. Otherwise, it should return the string “false”. This value is then compared with “false” using the Fn::Equals intrinsic function.
• This condition will be then used later in the template to conditionally create the LambdaFunctionRole role as shown below.
  

The idea here is when the primary stack is deployed in us-east-1, the macro will return “false” as the LambdaFunctionRole role does not exist yet. Hence, the CreateGlobalResources condition will be set to true and the LambdaFunctionRole will be created. When the stack is deployed in us-west-1, the macro will return “true” and the CreateGlobalResources condition will be set to false. Hence, the role will not be created again.

Let’s See The Macro Code

Now that we understand how the Dynamic Condition Expression is created, let’s take a look at the macro code.

{
  "AWSTemplateFormatVersion": "2010-09-09",
  "Description": "A stack to provide utility methods for resources.",
  "Parameters": {
    "CreateLambdaRole": {
      "Description": "Whether to create the lambda role.",
      "Type": "String",
      "AllowedValues": ["true", "false"],
      "Default": "true"
    }
  },
  "Conditions": {
    "CreateGlobalResources": {"Fn::Equals": ["true", {"Ref": "CreateLambdaRole"}]}
  },
  "Resources": {
    "ResourceHelper": {
      "Type": "AWS::CloudFormation::Macro",
      "Properties": {
        "Name": {"Ref": "AWS::StackName"},
        "Description": "A macro to provide utility methods for resources.",
        "FunctionName": {"Fn::GetAtt": ["ResourceHelperLambda", "Arn"]}
      }
    },
    "ResourceHelperLambda": {
      "Type": "AWS::Lambda::Function",
      "Properties": {
        "FunctionName": "ResourceHelperLambda",
        "Handler": "index.handler",
        "Runtime": "nodejs8.10",
        "Role": {"Fn::Join": ["", ["arn:aws:iam::", {"Ref": "AWS::AccountId"}, ":role/ResourceHelperLambdaRole"]]},
        "MemorySize": "128",
        "Timeout": "30",
        "Code": {
          "ZipFile": {"Fn::Join": ["", [
            "const AWS = require('aws-sdk');\n",
            "AWS.config.update({region: '", {"Ref": "AWS::Region"}, "'});\n",
            "const iam = new AWS.IAM();\n",
            "\n",
            "exports.handler = (event, context, callback) => {\n",
            "  console.log('handler(): event: ' + JSON.stringify(event));\n",
            "  const params = event.params;\n",
            "  const op = params.Operation;\n",
			" const roleName = params.RoleName;\n",
            "  if (op == 'roleExists') {\n",
            "    var request = {\n",
            "      RoleName: roleName\n",
            "    };\n",
            "    iam.waitFor('roleExists', request, function(err, data) {\n",
            "      if (err) {\n",
            "        // Role does not exist\n",
            "        handleResponse(null, 'true');\n",
            "      }\n",
            "      else if (data.Role) {\n",
            "        // Role exists\n",
            "        handleResponse(null, 'false');\n",
            "      }\n",
            "      else {\n",
            "        handleResponse(new Error(`Could not get information about role '${params.RoleName}'.`), null);\n",
            "      }\n",
            "    });\n",
            "  }\n",
            "  else {\n",
            "    handleResponse(new Error(`Unsupported operation '${Operation}'.`), null);\n",
            "  }\n",
            "  const handleResponse = function(err, data) {\n",
            "    var response = {\n",
            "      status: 'SUCCESS',\n",
            "      requestId: event.requestId,\n",
            "    };\n",
            "    if (err) {\n",
            "      console.log('handleResponse(): ' + err);\n",
            "      response.status = 'FAILURE';\n",
            "    }\n",
            "    else {\n",
            "      response.fragment = data;\n",
            "    }\n",
            "    console.log('handleResponse(): response: ' + JSON.stringify(response));\n",
            "    callback(null, response);\n",
            "  };\n",
            "}\n"
          ]]}
        }
      }
    },
    "ResourceHelperLambdaRole": {
      "Type": "AWS::IAM::Role",
      "Condition": "CreateGlobalResources",
      "Properties": {
        "RoleName": "ResourceHelperLambdaRole",
        "AssumeRolePolicyDocument": {
          "Version": "2012-10-17",
          "Statement": [{
            "Effect": "Allow",
            "Principal": {
              "Service": "lambda.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
          }]
        },
        "ManagedPolicyArns": [
          "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole",
          "arn:aws:iam::aws:policy/IAMReadOnlyAccess"
        ]
      }
    },
    "ResourceHelperLambdaLogGroup": {
      "Type": "AWS::Logs::LogGroup",
      "Properties": {
        "LogGroupName": {"Fn::Join": ["", ["/aws/lambda/", {"Ref": "ResourceHelperLambda"}]]},
        "RetentionInDays": 1
      }
    }
  }
}

As we know, the purpose of this macro is to prepare the Dynamic Condition Expression text with value as either “true” (if the role exists) or “false”. A macro is essentially a lambda-based stack that exists in the same region as the consuming stack. Here, I am using Node.js for implementation. If you are not familiar with it, do not worry. I will explain the important aspects below.

• The macro CFN template takes a single parameter – CreateLambdaRole. It is referred by the CreateGlobalResources condition that is used to conditionally create the IAM role required for the macro lambda. Do not confuse this with the use case we saw earlier. The condition here is strictly for the macro lambda role only. Can you guess why? Perhaps you got it. Since there are 2 AWS regions in our sample deployment, we will have 2 deployments of the macro stack as well. But, we would create the IAM role for the macro lambda only once and use it for both the stacks. So, when the macro stack is created in the primary region (us-east-1), the CreateLambdaRole parameter will be set to “true” and the macro lambda role will be created. And, vice-versa for us-west-1.
• The first resource is the ResourceHelper macro itself.
• The next resource is the ResourceHelperLambda that provides macro implementation.
  • In its Code block, the AWS SDK is initialized first.
  • Next in the handler function, we are first extracting the Operation and RoleName parameters. Apart from these parameters, the macro also receives other request data in a well-defined format, such as the requestId, which is a unique identifier for a given macro call. The following screenshot shows a sample macro request.
    
  • This is followed by a check to confirm if the request operation is roleExists. If so, an IAM SDK call is issued to check whether the supplied role already exists.
  • If the role exists, a string with value ‘true’ is returned. Otherwise, ‘false’ is returned. This string output is then used to prepare the lambda response in a well-defined format, which includes additional fields, such as status. The following screenshot shows a sample macro response. The content of the fragment field is our Dynamic Condition Expression text.
    
  • The ResourceHelperLambdaRole is the IAM role used by the macro lambda.
  • Finally, the ResourceHelperLambdaLogGroup is the log group used by the macro lambda.

In this article, we saw how to use macros to create CFN condition expressions dynamically. This capability can be extremely useful, especially if you are trying to avoid splitting provisioning logic in multiple places, such as some in CFN and some via scripts. If you have multiple such common methods, you could create one or more reusable macros that can be used by multiple stacks thus increasing the reusability. So, next time you have a situation where you would want the CFN conditions to be dynamic, you may want to consider creating Dynamic Condition Expressions using macros.

Happy coding!
– Nitin

If you liked this post, you will find my AWS CloudFormation Deep Dive course useful that focuses on many such best practices, techniques and hands-on examples to use CloudFormation in real-world deployments.

The post How To Create Dynamic Condition Expressions In AWS CloudFormation Using Macros appeared first on Cloud Nine Apps.

Smart Home solutions are becoming increasingly popular, especially with the continuous value they add to our routine. On top of that, many of these are becoming simpler to implement with the time and these does not need a lot of expertise. Always remember the key to have a successful smart home is to look for solutions that add value to your routine and lifestyle. In this post, I will cover some of the favorites that I consider to be the best Smart Home solutions. These are also sometimes referred by other names, such as smarthouse, intelligent home, homesmart, house control, automation system, and so on. I will keep this post updated. So, feel free to bookmark and check occasionally for any updates.

My Favorite Smart Home Solutions

Following is the list in no particular order. Feel free to jump to the specific one that you are interested in.

• Automate indoor lighting and devices using Smart Switches/Dimmers
• Automate lock/unlock the door using a Smart Lock
• Manage heating/cooling smartly and more efficiently using Smart Thermostats
• Automate lighting and devices using Smart Outlets
• Use voice to perform simple home automation tasks like turn lights on/off using a Smart Voice Assistant like Alexa

Automate indoor lighting and devices using Smart Switches/Dimmers

Key Benefits

• Turn on/off remotely.
• Turn on/off on an event, such as a sunset.
• Turn on/off on a schedule, such as 9 PM on weekdays.
• It can also be used as a regular switch. Yes, I do get this question asked from time to time. It means that you can turn it on/off manually.
• It could be used in combination with other smart devices to make more useful scenarios, such as in the morning turn off the lights and start the coffee maker attached to the outlet.

Click here to learn more.

Automate lock/unlock the door using a Smart Lock

Key Benefits

• Keypad support: Several smart locks now offer keypads to enter the unlock key and to program keys.
• Programmable keys: A smart lock allows setting up multiple keys. For example, depending on your needs you can set up a key for each family member and for anyone who regularly visits home. The advantage of a key per user is you can track which key was used to unlock. Not everyone may need a key for every single user. But, you would at least want different keys for family members versus other people coming into the home regularly. In any case, it is good to know that such a capability is available if need be.
• Open/close lock remotely: This capability is precisely what it says. You do not need to be on your home network to lock/unlock the door remotely.
• Open/lock with a key like a regular key. This is useful for regular access or in case the lock battery dies.

Click here to learn more.

Manage heating/cooling smartly and more efficiently using Smart Thermostats

Key Benefits

• Automatic presence detection and switching to/from the energy-saving mode.
• Schedule-based settings (such as different settings for sleep versus during the day).
• It can easily be integrated with a smart hub to perform more intelligent functions. For example, when you depart home, you can trigger a routine or a scenario that locks the doors and puts the thermostat in the Away mode.
• Traditional thermostat capabilities, such as changing the temperature on the fly, turning the fan on/off, turning the heat on/off, etc.

Click here to learn more.

Automate lighting and devices using Smart Outlets

Key Benefits

• Turn on/off remotely.
• Turn on/off on an event, such as a sunset.
• Turn on/off on a schedule, such as 7 AM on weekdays.
• It could be used in combination with other smart devices to make more useful scenarios, such as in the morning turn off the lights and start the coffee maker attached to the outlet.

Click here to learn more.

Use voice to perform simple home automation tasks like turn lights on/off using a Smart Voice Assistant like Amazon Echo

Key Benefits

• A Smart Voice Assistant like Amazon Echo (or Alexa) can help in making a voice-enabled smart home to control typical devices like smart lights, switches, outlets, thermostats, cameras and so on.
• It is a platform that continues to become better and offers a lot more capabilities. For example, Alexa offers several skills ranging from general knowledge, science to entertainment.
• It can be used as a speaker.
• It also supports audio out.
• It can be paired with a Bluetooth speaker.

Click here to learn more.

Enjoy your smart home!
– Nitin

The post Best Smart Home Solutions appeared first on Cloud Nine Apps.

Software as a Service (SaaS) has been a predominant model for many software vendors. It helps similarly delivering software as a Cloud vendor delivers infrastructure services. SaaS applications are often deployed on a public cloud, like Amazon Cloud (AWS), Microsoft Azure, Google Cloud and so on. However, at times the organization may choose to use their datacenter (a.k.a. private cloud) to host the SaaS application and leverage their investment in the infrastructure. When you are designing SaaS applications, it takes more than just deploying application bits to the Cloud. Taking proper design considerations can not only help you in accomplishing a good design, but it can also help you in reducing costs and manage your deployment more effectively. In this post, I will cover some key considerations and tips to design SaaS applications that I have found useful over the years.

How Is Designing Applications For Cloud Different From On-premise Applications Design?

That’s a valid question that many Architects face, especially in the early phases. There are certain subtle differences. Let’s look at some of these just to get the perspective.

• Better Modularization: If you have a monolithic application with a huge footprint, it is perhaps wise to see if it can be broken into logical components that can be deployed separately. This not only improves modularity but helps you reduce the footprint of the application. Let’s say you have an application that uses background jobs to refresh data. You could segregate the core application and the background jobs as 2 (or more) components that can be deployed separately. This will reduce the footprint of the core application. So, you could potentially choose a smaller resource size. Also, depending on the needs, you can scale these two independently. So, if there is an increase in demand for background jobs, you can increase its capacity and likewise for the application tier. Since the resource size for each of these is small, scaling only the required tier/component will lead to an overall lower cost than more bulky resources for the monolith. Makes sense?
• Application is always up-to-date: This is a big shift for many on-premise applications. In the Cloud, customers typically expect the application to be always on the latest version. Now, if you think about it as an Architect it means you are not only able to update the application bits but also upgrade customer data with preferably no customer involvement. That is, it is completely transparent to them.

These are just some of the differences. But, you get the point.

Key Design Considerations for SaaS

When you are designing an application for Cloud, you want to consider the following key points.

• Choose appropriate Cloud services: Of course, you are deploying to Cloud. But, which services do you want to use? Are you simply going to use Infrastructure as a Service (IaaS)? Or are you going to take advantage of some Platform as a Service (PaaS) capabilities as well? The answer may not be always straightforward. So, here are some guidelines.
  • Are you going to have the same application deployed to multiple Cloud platforms or on-premise as well? In that case, it may make sense to not have (or minimize) Cloud vendor-specific services and stick to more of IaaS services.
  • Cost should be an important consideration in choosing the services. For example, certain PaaS services that are Cloud vendor managed may be managed by your team itself to reduce cost. While this may not make sense for every service, it is worth exploring.
  • Keep your team expertise in mind. What would it take to use a certain Cloud service? And, if the team were to also maintain the underlying infrastructure, what skills would be needed?
• Design for failure: Designing fault-tolerant and highly available applications is fundamental to Cloud. Assume that your application will run into issues and how you will ensure that it continues to serve the users. These could be application failures or underlying infrastructure failures. There are a few useful capabilities offered by Cloud vendors to help here.
  • Use a Load Balancer: You can put the application nodes behind a Load Balancer for both load-balancing purposes as well as to make sure that even if one or more nodes go down, the application is served via the other nodes.
  • Geographically distributed application: Several Cloud vendors offer capabilities to spread the application across multiple geographical areas so that even if one area is impacted (say, due to a natural disaster), the application can be served from the other areas. For example, AWS supports deploying an application across multiple Availability Zones.
• Modularize your application: As we discussed in the earlier section, segregating components that can be deployed and managed separately can help reduce the footprint of the application and thus reduce the cost of the infrastructure. You may also consider making some of these components as microservices. The microservice approach can be particularly useful if there are other potential consumers besides your application. Now, that does not mean, you go overboard and create unnecessary components. Hence, one way to do this is to make components that can be deployed separately (such as core application versus background jobs).
• Security: Security involves many aspects – from securing your infrastructure to application. Some of the key aspects include ensuring that only the required ports are opened, using as minimal privileges on the resources as possible, having proper role-based access control, use of encryption, and so on. Security should not be looked at as a one-time deal. It is an on-going process that should improve and evolve over time.
• Multi-tenancy: A key benefit of running in the Cloud is being able to serve multiple customers using the same instance of the application. This brings out some obvious challenges in the application design to ensure that each customer’s data is segregated for both security and regulatory purposes. Some teams choose to go with a different persistent storage instance per customer, such as a separate database per customer. And, some choose to segregate data using row-level identifiers. Regardless of which approach you take, it is important to ensure that the architecture meets the scalability and security needs. For example, if you choose to go with a database per customer, you can host multiple databases on one RDS instance. And, when you run out of capacity, you can stand up another RDS instance.
• Zero/Minimal Downtime and Seamless Upgrades: Believe it or not, many customers expect that SaaS applications will have zero or very minimal downtime and since these are often managed by the same company who built the application, it should be upgraded seamlessly. The challenge is your application may not have been designed to handle upgrades smoothly, especially if it is a pre-existing application being converted to a SaaS application. There are 2 key aspects to consider a) deploying application bits and files b) handling persistent store upgrades. For rolling out application bits strategies like Blue/Green deployment can be used in which the new release is deployed to a new stack, tested and made live if the rollout was successful. The older stack resources can be decommissioned and reclaimed at a later point. One approach to achieve seamless upgrades is to make the underlying data model n – 1 compatible. What that means is if the release being deployed is of data model version n, it’s data model is backward compatible with the previous data model version (n – 1) thus ensuring that the upgrade will not break it. How can you ensure that? This requires incorporating discipline throughout your development cycle and following certain guidelines, like not deleting any columns, providing necessary upgrade scripts to handle any data migration needs, and so on. And, in the event upgrade is not successful, having support to rollback the upgrade. Now, you can understand this is not only technically challenging as this involves data migration and rollback, but it could also lead to a significantly slower rollout. Hence, you have to evaluate carefully what is reasonable for your application needs and implement the solution accordingly.
• Optimal Cost: As you progress through your application and deployment design, you would be able to come up with multiple approaches to deploy the same application. However, one key aspect to be successful in SaaS is to ensure that you choose the most cost-effective model that not only meets your immediate needs but can cater to at least the near future needs, such as when the demand rises or slows down. You do not want to be spending overtly, but not so less that the application starts choking with very few users. Hence, it is important to strike the right balance. A rule of thumb that I like to follow is when choosing resource sizing always go on the conservative side. And, if the testing reveals higher configuration is needed, then only increase.

DevOps Considerations For SaaS

DevOps is so critical for SaaS that it is worth discussing it separately. The following are some key considerations.

• Continuous Delivery: The DevOps pipelines should be able to take the checked-in code, produce a build from it that then passes through various stages (QA, performance, final go/no go checks, production deploy) in an automated manner. This may involve having multiple pipelines (typically, per stage) and having an uber pipeline that pushes the build through each of these stages. Now, the pipelines may also take some time to develop, but it is a good idea to start defining the contracts for each pipeline so that the consumer pipelines do not need to worry about the details. Eventually, the goal should be to get completely hands-free or as close to it as possible.
• Use Version Control for everything including DevOps changes: For application code, it is generally well understood to use the master branch of the source control. However, it is equally important to do the same for any DevOps changes. For example, when you are rolling out infrastructure changes, these should also be checked into the source control, tested and then pushed to production.
• Agile Infrastructure: To be successful at SaaS, you want to make sure that your infrastructure is agile and can cope up with the changes in demand. As the demand goes up, it can scale appropriate tier and when the demand goes down release the non-required resources. This requires a certain level of experimentation and testing to get to the right balance. For example, you can use AWS auto-scaling capabilities to automatically scale up/down the infrastructure.
• Monitoring and Alerts: The stacks these days have multiple moving parts and troubleshooting could be a bit of a challenge. Hence, it is important to have the right monitoring and alerting mechanisms in place so that when things go wrong, you can troubleshoot the problem more quickly. It is a good idea to leverage from some of the core Cloud monitoring capabilities like centralized logging, alarms, and notifications on errors.

Other Considerations For SaaS

• Planning and Prioritization: Like any other successful project, SaaS projects also require planning and prioritization. While everyone wants to go for goals like “push every check in to production”, see what makes the most business sense and prioritize the important things first. Of course, having a stretch goal is not wrong. But, it is important to get the important things right first. For example, if you do not have a good unit testing and automation coverage and you are trying to push every code change to production, even if you accomplish it, the usefulness is questionable. It can backfire because things can start breaking too quickly in production and then the R&D team will be consumed in handling those.
• Monetization Model: SaaS also impacts the monetization model. While in on-premise you may be fine selling license for a certain amount, in SaaS you may have to rethink what is the most suitable model for your business. Do you want to use a subscription-based model, utilization-based model, a hybrid model, or something else altogether?

Hopefully, you got a better insight into what it takes to design a Cloud-based or SaaS application. It is certainly an enriching experience to see your application that involves so many different aspects, go live in production. As I always say, “Cloud is a journey and not a destination”. So, keep learning and evolving.

Happy designing!
– Nitin

If you liked this post, you will find my AWS Advanced For Developers course helpful that focuses on many such best practices and techniques to design and deploy real-world applications in AWS.

The post How To Design Applications For Cloud (SaaS) appeared first on Cloud Nine Apps.

Following are the highlights of this release.

• A simple periodic notification enhancement to remind about visiting the app to check for any price drops and managing the purchases. This will help in not missing out on deals.
• Other minor improvements and fixes

Check it out now! We would love to hear your feedback.

The post Shopping Guru 1.1.3 Available appeared first on Cloud Nine Apps.