The first lesson of going serverless with AWS is that you’re not truly going serverless in the literal sense. You’re resigning from the overhead and responsibility of provisioning, maintaining and administering servers and handing the responsibility for the AWS. It almost sounds too good to be true, right?
AWS offers a robust collection of products that can be used to replace the functions that servers are currently carrying out in your applications. A handful of these services will be detailed in this blog but there are plenty more to explore. ParkMyCloud provides a convenient list of services categorized by use case.
So what exactly is AWS Serverless? Using AWS Serverless means to build a serverless application using AWS’s fully-fledged army of services. This concept can seem a bit abstract at first. To provide a tangible example, let’s say that you’re thinking about building a serverless web application. The architecture below provides an example of how this can be accomplished using AWS services. AWS provides a good tutorial here that serves as a guide to creating your first AWS Serverless web application with this architecture.
The components shown in the example above are described in more detail below. Keep in mind that this architecture is only one example of how AWS services can be combined to build a serverless application.
S3 provides a place to store data hosted by AWS. To get started, create a bucket which is a structure that serves as a container for related resources. Then upload your data to the bucket and choose a region for Amazon to store your data in. You can conveniently choose a region located near your end-users to reduce latency, if applicable.
Amazon Cognito handles the user registration process and uses the user pool paradigm to manage user data and workflow. A user pool is a user directory that contains all user information. Amazon Cognito handles all processes related to users, including the implementation of a registration flow, sending registration emails, provisioning JWTs and more. Add two-factor authentication or SAML with the click of a button. These processes are fully customizable in the AWS Cognito interface.
Amazon API Gateway allows you to quickly create and publish APIs. API management and maintenance become simple since AWS takes care of most of the dirty work. APIs created with AWS Gateway can effortlessly process hundreds of thousands of concurrent API calls providing excellent reliability and capacity.
AWS Lambda allows you to write code that lives on servers managed by AWS. Lambda functions can be automatically triggered by other AWS services or can be called from a web or mobile app. For example, you could create an API using Amazon API Gateway which then triggers a Lambda function to execute a post action on a database. The use cases for AWS Lambda are endless and extend far beyond the scope of the web application architecture outlined above. Check out the Youtube playlist found here to see how big companies are using AWS Lambda.
While AWS provides great interfaces for the implementation of each of their services, it’s much more convenient to be able to set services up and running from the command line. AWS SAM makes this possible. Define your serverless application by using a template that specifies all functions, API’s permissions, configurations, and events. Then use the AWS SAM CLI to package and deploy your application. The CLI also allows you to deploy and debug Lambda functions locally rather than having to use the AWS web interface for manipulation.
Quick! Let’s start transitioning all of our web applications to be serverless. Not so fast. Developing serverless applications will require shifts in development flow and time invested in gaining deeper understandings of AWS services. It may be overwhelming to take on the development of an entire serverless application at once. One of the positives of using AWS services is that they can be implemented independently. Transitioning just one API or implementing Amazon Cognitio could be a great first step to exploring what AWS Serverless has to offer.
Almost all AWS services use an elastic cost model meaning that you only pay for what you use, similar to how you might pay for your water or electric utilities at home. Services scale in size to account for varying resource utilization over time. This model could prove to be very beneficial for applications or jobs that only use resources a few times a month. Rather than paying a monthly fee for a server, you pay for what you use, when you use it. Read more about the AWS service pricing model here.
The opportunities that AWS Serverless provides are endless and may alleviate a lot of the overhead that can result from provisioning, managing and maintaining servers. Since every application is different, it comes down to whether the elastic pricing and time saved by letting go of server management can be beneficial in your situation.
At Woodridge Software, security is something that we take very seriously. As technology continues to rapidly evolve, it seems like hackers’ methods of attacking modern software are evolving at an even faster pace. Unfortunately, the average software developer has little to no understanding of the miscellaneous attacks that are used by hackers, nor do they completely understand how to help prevent them. For my latest tech seminar, I decided to review our current methods of securing web apps, as well as areas where we can continue to improve.
The web has become the largest source of information and it houses the interfaces to an unimaginable amount of data. Due to its ease of access, it has become one of the leading mechanisms for modern cyber attacks.
Nearly every business has some sort of web application. Whether it be on a private intranet or available to the public, it is important that all of the software developers involved in the making of a web app are security-aware. Among the most common attacks are cross-site scripting (XSS), cross-site request forgeries (CSRF), and SQL injection (SQLI). In order best to understand how to prevent these attacks, it’s important to understand how they can occur. The best way to do that is to simply do some research and write up small examples that illustrate the attacks. They don’t have to be cutting-edge examples – just enough to get the point across. From there, the example should guide you on how to prevent these attacks. Most modern web frameworks have tools built-in for mitigating such attacks, and understanding how these attacks occur will help you to understand how these tools are implemented in order to properly use them.
Every developer needs a basic understanding of cryptography.
Specifically, the differences between asymmetric and symmetric cryptography, a high-level understanding of cryptographically secure random number generators, cryptographic hashes, digital signatures, and message authentication codes. Any modern web application will most likely have some form of encryption (typically, communication over HTTPS, password identifiers stored via cryptographic hash, and sensitive information stored via encryption with some form of integrity check such as using an HMAC). It’s also considered a best practice to implement at-rest encryption on both your physical and cloud resources. Improper usage of cryptography (or no usage) is a sure way of putting your data at risk.
This, of course, is not a comprehensive list and is merely an overview of a few important things to consider when building your next web app. Other things worth mentioning are rate-limiting requests (especially on login and registration), utilizing a Content Security Policy (CSP), ensuring your web application server is configured properly, security logs, etc. At Woodridge, we are no strangers to securing web apps. In fact, we can even help you take your existing applications and get them up to par to pass your next penetration test, which you should be performing at least once a year!
Lorenzo Gallegos is a senior software developer at Woodridge Software, a custom software development firm located near Denver, Colorado. Woodridge specializes in Web, Android, and iOS development and works with a variety of clients ranging from startups to Fortune 500 companies.
Maintaining code and appearance for your web app across multiple browsers is not always trivial. Different browsers may only implement certain features and sometimes different browsers will implement the same feature differently. You want to support as many users as possible, but doing so can increase development costs. So how do you choose which browsers you need to support?
If you choose to support multiple browsers, you may encounter bugs that appear in one browser which are absent in all others. There may be differences in how the developer or designer needs to apply a design to the different browsers. This leads to additional development and maintenance time, which has a corresponding cost. In addition, if your web application has hundreds or thousands of users, not supporting an important browser can increase the number of support emails and calls.
If you have a web app for use by a small number of employees, you might only need to support the latest version of a single browser. This can lower development and maintenance costs. On the other hand, if you’re running an online store and rely upon a large number of sales, making sure your website supports most browsers can bring in more customers. You can choose to not do so and make suggestions, such as “This website is optimized for Google Chrome”, but there’s no guarantee the user will switch from their preferred browser. Even if they do switch, having to do so is inconvenient. So, if you don’t have a small enough group of users to justify supporting a single browser, you need to consider which browsers are worth the additional cost.
If your web-app is already out in the wild and you use Google Analytics, you can view the browser breakdown for your current users. For our website, it looks like Chrome, Safari, and Firefox are the big three, with IE/Edge also seeing users.
Using tools like Google Analytics provides you with real data that is specific to your user base. With these types of tools, you can quickly get an idea of which browsers you need to support for your users.
If you don’t have information through a tool like Google Analytics, a good approach is to target the browsers that are currently the most commonly used. There are a few places you can look for this information, such as Stat Counter and W3Counter. It’s worth the time to examine a few different sites for this information – they all have different sources for their data. The provided percentages may also represent different data. For example, the percentage of users using a specific browser vs. the number of webpages viewed by a particular browser.
For January 2017, Stat Counter shows:
And W3Counter shows:
According to both tests, Chrome and Safari are the important browsers to support. But Stat Counter shows UC Browser third (a browser which, before today, I have not heard of), whereas W3Counter doesn’t show it at all. So, it’s important to compare multiple resources to get an accurate picture of the most common browsers. You can start by supporting the two or three most common browsers and increase support for others over time.
On the development side, browsers vary in support for different standards and features. This may result in having to use multiple code and style implementations for different browsers. Supporting older versions of browsers can prevent developers from using newer versions of ECMAScript (used for controlling interactive behavior on a webpage – information on support for the newest version can be found here). There are also new CSS standards and features for designers which may only be usable on newer browsers, such as FlexBox. So, supporting older versions of browsers limits the newer features available to your development team. These newer features may speed up development time, and the absence of some of these features can make certain tasks impossible or finicky for a particular browser. It’s important to have a discussion with your development team about which features of your web app are possible with the browsers you want to support.
There’s a lot to consider when choosing which browsers to support – costs, user base, and technology constraints. Typically, we find it easy to maintain Chrome, Firefox, and Safari (and for some of our customers, we also make sure our code is compatible with older versions of Internet Explorer if their users require it). When choosing which browsers your website or web app will support, it is important to make your decision based upon the best information you have available.
Over the past few years, as AWS has become the defacto standard for Woodridge Software’s back end systems, we have deployed dozens of mobile applications. Most applications are mission-critical to our customers, however, the total number of users varies widely. Some of our apps have maybe 10 or so users, others have 100,000+ per day. In this blog, we’ll discuss some of the similarities in the deployments of small and large scale applications and the strategies we use to help scale to our larger implementations.
Database scalability is the ability to consistently handle the growth of data that an application will house during its lifetime. You can host any relational database on Amazon such as mySQL or PostGres or use noSQL databases such as Mongo. Amazon also has its own versions of both, Aurora is its relational database and DynamoDB is its version of noSQL. AWS has implemented autoscaling services for most relational databases using service they call RDS(Relational Database Service) these help you scale your database, however, we have found that using Aurora often is the easiest to implement. The same is true for DynamoDB where AWS guarantees throughput and single-digit millisecond latency. The choice of using a noSQL or SQL database is of course chosen based on the data being stored for the mobile app.
System bottlenecks occur when several resources all have to rely on one resource. If that one resource becomes overwhelmed with requests then it can cause a severe decrease in system performance or even a loss of availability.
Fault-tolerance allows a system to keep operating at normal (or close to normal) behavior in the case of a failure. Hardware failure, power loss, and physical damage caused by natural disasters are some of the most common non-software reasons for system failure. In order for a system to remain fault-tolerant, it must be able to continue functioning with a complete loss of a resource.
Ease of maintenance is often lost when providing a highly-scalable and reliable system due to an increase in number machines, resources that require specific attention, a more complicated codebase, and possibly having to build and maintain dedicated server farms.
Cost is often hard to balance when trying to provide a reliable web system because it is difficult to predict how many resources are needed, and you often end up paying for far more than is actually ideal.
Best practices for large-scale cloud applications utilize many AWS (Amazon Web Services), Google, and Apple utilities to provide the ideal web system.
Utilizing these services and utilities also has other benefits including additional security mechanisms and no need to maintain physical machines. Amazon, Apple, and Google’s facilities are all safe and secure with top of the line disaster-recovery mechanisms in place including physical security, power backups, etc. The automatic scaling provided by Amazon also ensures that the system only ever includes necessary resources, which keeps costs to a minimum.
This blog is just a high-level overview of the systems we put in place, but hopefully, it takes some of the mystery out of what Amazon is delivering. Those of us in the software development industry know well how Amazon is helping make our lives easier. Many of these services we used to have to set up manually, with countless cron jobs and monitoring. In the custom software world we work in, this used to mean more cost for our customers and lower reliability. By leveraging these services we can reduce our costs and keep our mobile apps humming along. Now if only Amazon had a way to update mobile code for each new iOS & Android release, that would be something… Then again we don’t want our business to be too easy.
In this slideshow, Zack provides an overview of e-commerce, covering online transactions flows, payment gateways, merchant accounts, e-commerce platforms, and PCI compliance.
Dedicated (Authorize.net, PayLeap)
Aggregate (Stripe, PayPal)
|MERCHANTLEVEL||TRANSACTIONS/YEAR||ON-SITE ASSESS||QUARTERLY NET SCAN||SELF-ASSESS|
|1.||> 6 million||X||X|
|3.||20,000 – 1 million||Maybe||X|
Level 1 & 2 merchants must have an annual audit by a certified Qualified Security Assessor (QSA)
They must also have their network scanned quarterly by an Approved Scanning Vendor (ASV)
Level 3 & 4 merchants are eligible to use the Self-Assessment Questionnaire (SAQ)
|YOUR PAYMENT PROCESSING||SAQ|
|All cardholder data functions outsourced||A|
|Cardholder functions performed locally, but no cardholder data stored||C|
|Cardholder functions performed locally, and cardholder data stored||D|
To qualify for SAQ-A no sensitive information can ever touch the website!
Sensitive information includes the card number, expiration date, and card code.
If the site does handle cardholder information a quarterly network audit is required.