Today, small teams are launching Internet-based projects within four months with only two developers. In this case, it was a Zillow like system for commercial real state. This is not a one off fluke. A Cloud Guru built an online training system within months with a few people. In 6 months, they scaled to 40,000 users without having to manage servers. So, how did they achieve these results? By using service full.
Author of the “DevOps Handbook,” Patrick Debois, has proposed the idea in several of his presentations that it is not so much “serverless” as “service full.” Service full is about heavily leveraging Internet and cloud services along with serverless compute technology to fill in the gaps. The development team integrates all of these services from a number of vendors to create the server-side part of the system equation. Serverless functions fill any gaps not provided by these services. This allows the development team to focus on delivering business value to the customer.
By applying these concepts correctly, teams are able to put most of their development effort in the user interface. This means they do not need to build out a server-side stack. Operations is smaller as they do not manage servers, be it physical or in the cloud. Well you might think this is expensive, as they are using all these different services. For startups, they typically start off in the free tier or the least expensive tier. This means their costs are extremely low or there are no costs. By now enterprise readers are dismissing the idea, as it does not apply to them, but it does apply!
Your Company is Already Part Way There
If your business has an Internet site or app, they most likely are already using some Internet based services. These are services your business is not going to create, as they add no strategic value to your company, but they improve the user experience. Some good examples of services your company may already be using are:
- Maps (Google, MapQuest, etc.)
- Analytics Services (Google, New Relic, etc.)
- Content Delivery Networks (CDN) (AWS, Level 3, etc.)
Creating services like this are cost prohibitive for a company to create, even a global enterprise, so they use them. These services are but a few possible services your company may use to deliver a quality experience to your users. Maps are great way to show your user how to find an office or store. Analytics are great for improving user’s experience and increasing traffic flow. CDN is great for increasing speed to the user, which improves the user experience. Now expand this to the rest of your company Internet footprint and there is great potential.
Service full is a new way of launching an Internet based service to your customers, which means it is way easier and cheaper for competitors to launch and scale. Therefore, this is an opportunity to learn and adapt for all types of companies from startups to global enterprises. No matter if your company can build a suite of systems on the Internet or not. It is about being worth the ROI between your company doing it or using an Internet service. To see the potential ROI of Internet services, let’s look at the benefits and characteristics of a service full design.
Benefits of Service Full to a Business
With the service full concept, a team of developers is primarily focused on the user interface. This means there are zero to a few people for server-side. Serverless fills any gaps not covered by the Internet services, which may require server-side developers. This results in smaller teams to implement projects and typically in shorter time, since these Internet services are ready to use by your development team. From an IT perspective this is huge.
With it taking less people to implement an Internet-based site, app or service, they can do more with less. This opens up IT to have more projects going at the same time to meet business demand with the same amount of people. Let’s look at service full further to see how it achieves these benefits.
Characteristics of Service full
Beyond the leveraging Internet services and serverless technology, service full has a variety of characteristics, which in themselves are great advantages. Since the service full leverages services and serverless technologies, the code base is smaller. This in turn reduces the size of the team required, as there is little server-side and operations needs. Everything becomes distributed, which is a big departure from having everything in one environment. Built on Internet services, these services’ designs support large scale and global users. All of this is possible with good security, which needs to be built in up front. Let’s break these assertions down further.
Smaller Code Base
In a full stack solution, a team needs to build out everything, especially if they are not going to leverage existing services. This typically means writing code to handle data for each layer of the solution, even for create, read, update, and delete (CRUD) operations. This code needs to be tested, which increases the need for more code. All this code, be it source code or tests code is places for bugs, which introduces rework and sucks time away from the team.
The code base of service full site is going to consist of the software for the client, its tests and any dependencies. Nothing new here, but the server-side portion typically required in a full stack implementation is replaced with settings, polices, rules and other data for services supporting the client. In some cases, serverless technology fills the gaps not supported by the Internet services. These services and serverless technology still needs to be validated, which can be done with tests. This includes unit, end-to-end and integration testing, which should contain negative tests to validate security of the services. Overall, the result is a smaller code base, requiring less work and tests. This in turn requires less people.
Smaller Teams
In a full stack solution, a team needs to build out everything, which requires a number of people. You typically end up with a client-side person and a few server-side people. Then assumes your developers are writing unit and integration tests, while a tester is writing the end-to-end tests. So, at the end of the day you have 6 people in this example working a project. Your projects may differ, but we know from the examples above teams shrink with service full.
In a service full scenario, we have a couple of client-side person and a services person. In this example, as the one above, the people have their primary role, but need to work in the other roles in a limited capacity. This is required of a good cross-functional team. Again, we add in a tester for end-to-end testing. We end up with 3 people delivering the same solution. Based on the example in the beginning, they were able to do it with two developers in four months. This is a significant change and the same can be said for the operations side of the equation.
Small Operations Footprint
With service full, a team is consuming services designed for automation. Companies like A Cloud Guru have no serves to manage, which means they have no operations team in the traditional sense. This in turn, keeps their costs down significantly. This is a big advantage of service full.
A traditional operations scenario for the same application could vary depending on if it is on-premise or in the cloud. On-premise, you are looking at a group of roles, like:
- Network administrators
- System administrators
- Database administrators
- Application administrators
In some organizations, you have pre-production and production groups, which increases the number of people to support an application. In the cloud, this group may shrink based on implementation and automation in place. This is the opposite of a service full site. Its small operations footprint is one great advantage, but the reduced work on CRUD is even better.
CRUD Made Easy
As mentioned earlier, a full stack system needs code at almost each layer to pass data through the system. Writing this code to handle data takes time, effort, requires tests and is a place to introduce bugs. With a service full design, server-side code pieces do not exist.
All service full implementations, I have seen so far, leverages tools like Google’s Firebase, Amazon’s DynamoDB and similar technologies. These systems leverage tools to store and access data, typically through a REST API. These systems have proper security and restrictions to ensure data security and quality. In essence, these become the primary server of a service full application.
Now, the developers only need to create data objects on the client side. Less code, means less work, less time and less rework. This is a key part to the speed of the examples mentioned in the beginning of this post. These data storage systems are designed to scale.
Easy to Scale
Any service on the Internet not designed to scale will be out of business shortly. Therefore, services used in service full systems allow these systems to scale from the beginning, as long as the developer follows the guidelines provided by the service provider.
Most of these data services are based on a scale-out approach, which means the developer needs to create the correct partition key. As this key will help distribute the data for optimal performance at scale. Selecting the wrong key will result in poor performance, which may not be evident early on, but will show up over time. This is why load testing is important. These services are designed to scale, which makes development easy. However, the distributed model of service full is a bit hard to understand, if you ant not familiar with it.
Highly Distributed
People in IT and me included, think about software going from development to testing, then to staging, then to production. In our minds, these are isolated environments. If they were built on physical servers, they would be physically isolated. If they are in the cloud(IaaS), they would be isolated via features provided by the cloud provider. Either way, the systems and services are in the a specific environment, so they can only access other services in the same environment. With service full, the model is different.
In service full these service are distributed across the Internet and may not be operated by the same company. How does all these services work together to deliver service to a customer while not existing in the same environment? Can you have multiple environments with all these services?
At a basic level, these services work together by security and configuration. A service full system requires an authentication service, like Auth0, Amazon Cognito or similar service. These authentication services can provide tokens to access to other services on the Internet. For an example, Auth0 provides a guide to use their authentication service to access AWS services. After authentication, service access is determined by service configuration.
AWS has Identity and Access Management (IAM), which is a verify robust access control system and is integrated with all of the AWS services. Other services do not have such a complex system, but they are not as complex as AWS. However, almost any service requiring some type of authentication and authorization will have security settings. In the cases of database services, there are additional constraints that can be applied at the data level.
Advance Security
Full stack development typically has a database buried at the bottom. In some systems, if not most systems, the layer on top of it access it. This means the database connections have a lot of access to data, especially if user connections are not lowest privilege required for the user to use the site. OWASP has guidelines on database connection security and they highly recommend against this scenario. If someone can figure out how to exploit bad code between them and the data, then you have a data breach. This requires writing good code and good tests to avoid this issue.
With services like Amazon’s DynamoDB and Google’s Firebase they have security features which allow constraints to be applied based the user logged in. This means the user’s request is tied to them all the way to the data, not the connection. DynamoDB has fine grained access control, which can limit what is hidden or exposed based on user credentials. While Firebase has a similar capability with its rules. This goes beyond the OWASP recommendation of “The application should connect to the database with different credentials for every trust distinction.” Therefore, these service full systems have some good security when properly implemented.
Conclusion
The service full concept has already delivered value to startups launching new fully-functional services to the world within record time and with limited resources. Beyond the time and cost benefits, there are a number of other benefits previously mentioned with the service full concept. In addition, service full systems have their own unique characteristics, which is why service full has so many great benefits.
Imagine applying service full to your organization’s projects. How many more projects could your organization do? How faster would they execute? If you can answer these questions, then you might see the value of service full.
If interested in discussing service full or other technologies or concepts, please feel free to contact OSG.