Rethinking the Ways of Utilizing Cloud
Challenges in Web Services Arena
Web services, a term that has become so commonly used, and sometimes misused in the last few years, is an elegant, standards based approach to communicate between applications. Web services are software components that provide a standards based approach to communicate between applications. Web services are based on XML and leverage three core technologies, SOAP, SDL, and UDDI to deliver the “service.” In the pre-web services era, companies used EDI (Electronic Data Interchange) standards to communicate business transactions between business applications. Most of these are now done using Web Services.
“Application architects need to be judicious with the what, the how, and the why of exposing functionality via web services”
Now, with web services, it is a lot easier for businesses to communicate with each other. We can also use web services to communicate between our internal business applications and external SaaS applications. While this is a very handy way to communicate between disparate applications, unless you have a security model around web services, you don’t realize that you are potentially opening up your corporate assets and data to prying eyes. Some of the other security issues include: unauthorized access, parameter manipulation, network eavesdropping, DOS (denial of service) attacks, etc. When it comes to security, keep in mind that every door or access point you open up to your application functionality is yet another door that is opened for hackers and unwanted traffic. Application architects need to be judicious with the what, the how, and the way of exposing functionality via web services.
Secondly, from a publishing perspective, if you don’t architect your web services properly, you could be causing performance issues within your applications. You need a series of checks and balances to prevent against runaway queries. You also need to architect the security model to protect yourself from denial of service attacks. You also need an external manageability lawyer, to effectively monitor and manage your web services, which many people don’t think about.
We also suffer from the law of unintended consequences where a publisher of a web service provides a window of opportunity to potential reconnaissance --- which could then pave the way for a future targeted attack. Also, the publisher of the web service in most cases does not know the real and final end user. The end user accesses the service via a web browser by passing credentials. Architects need to keep these considerations in mind.
Web services also increase the level of complexity for development organizations. Development teams have to factor both internal and external stakeholders, as well as backward compatibility considerations before releasing new code into production.
Implementing DMZ and Firewalls
First, let us think about the world before AWS. You secured your corporate apps within your own firewall and then you granted access to those applications to people within your network. We protected the crown jewels and intellectual property by implementing demilitarized zones (DMZ) and multiple layers of firewalls.
Let us now fast forward to the AWS era. The minute you put something on AWS, such as your business applications or your data warehouse, you need to make sure only people in your network are granted access. Most IT practitioners overlook the potential exposure to company assets when deploying applications on the cloud (AWS or Azure). This would not have been an issue to consider with an internal on-premise or on-co location deployment. You need to architect and implement a VPN tunnel between your physical network and the AWS network and implement a virtual private cloud. That tranlastes to an extra level of overhead that you need to architect and maintain.
The other challenge is that an application is only as good as its availability. When you put an application on AWS, you also need the corresponding tools that can provide insight into the performance of that app at the server level and at the platform level. That means you must still invest in tools for proper app management and maintenance.
Emergence of SaaS-based Models
For me, one of the biggest changes is CapEx vs. OpEx. The emergence of SaaS-based models and cloud based deployments have made it extremely easy for me to now onboard and off-board applications. But while that is a boon, it can also be a curse if you don’t manage it properly. For example, I gave one of my staffers a free hand with our AWS deployment, but he had an double extra-large server running a relatively minor application. What he really needed was a much smaller deployment. It’s a common mistake with web services. You don’t realize that you are spending more than you actually need to, but the costs can quickly add up. So you really need to have visibility into how much you are spending. We then implemented a management tool on top of AWS that gives us more visibility into our spend and our cost drivers. As a result, we can go into AWS and tweak our deployment as needed, which allows us to save money.
Connecting Cloud-based Applications to Cloud-based Data warehouses
With Internet pipes becoming bigger, and with the emergence of reliable access to networks, it is now possible to have data in the cloud. In fact, you can have terabytes of data in the cloud. Many of my CIO friends used to be hesitant to put their data warehouse in the cloud. But now I’m seeing more and more companies willing to take that leap. They are starting with one data mart and quickly adding more datamarts as their comfort level rises. It is also becoming easier to connect cloud based applications to cloud-based data warehouses. So there is lots of action in that space today.
Ensuring Right Level fo Sataffing and Expertise
The cloud is not one-size-fits-all. Taking an on-premise application and deploying it on AWS does not automatically make it a cloud-based application. There is more to it. Remember that certain applications are not meant for the cloud. So don’t try to force fit those applications. Evaluate and deploy SaaS-based applications instead of trying to take your on-premise application and migrating it to the cloud.
Also, make sure you have the right level of staffing and expertise within your team to effectively manage applications on the cloud. When everything was in my own data center, I needed a huge staff to manage my network and to maintain my servers. I used to have a server person, a network management person, a patch person, etc. All those roles are now gone. People who want to architect and maintain applications in the cloud need to think differently. The challenges you face with a cloud-based deployment are completely different from the challenges you face with an on-premise deployment. So make sure you have the right staff with the right skills.
Also, invest in a strong single sign on platform for managing the effective on-boarding and off-boarding of users. Evaluate the security profiles of the vendors that you are working with. Have them present their SOC evaluations and do a site visit if needed to ascertain that you are choosing a vendor or partner that meets your security requirements.
There are many groundbreaking enhancements happening in the cloud space. Most big-box applications are slowly being rendered extinct, thanks to the agile and functional applications that are available today. Before investing in a solution, clearly define the problem that you are trying to solve. I have seen many instances where people start with the solution and then search for the problem.
Data and application integration are more key in a SaaS and cloud-based world than ever before. Invest in a strong application and data integration strategy and tool to effectively connect your business applications and data. Otherwise you run the risk of having islands or archipelago of data and information.
Big data and analytics are some of the hottest buzz words in the industry today. Before jumping into choosing a magical tool that supposedly solves all your big data or analytics problems, be clear on the business needs, the information needs, the data needs, and the true analytical needs. This is one area where I have seen an over-engineering of the solution.
Finally, don’t underestimate security and the effort it takes to keep your own environment secure. With the cloud, you are potentially exposing your crown jewels—your IP and your customer data—to the world. So you need to make sure you are secure and that you are in compliance with all regulatory requirements.