— (((Bob))) (@rober1236Jua) December 19, 2016
Last post on Cloud conversion dealt with dealing with massive migration business logic, and I suggested you try and manage complexity by breaking your information worker tasks in to those you don't understand and are custom, and those that are general tools leverage by users. General tools that give users freedom should be managed by SaaS, the most famous being Office 365 and Salesforce. The others should be migrated to IaaS in mass to reduce complexity of migration. If you are not happy with this simply model you need to budge at 6 month to 1 year application rationalization and conversion project.
I am going to skip that for a later post and concentrate now on how to make new things with a Cloud.
You will be migrating your existing systems to IaaS VMs, but for new solutions you will find that the best thing to do is PaaS, where you consume code or data storage without having to worry about infrastructure.
To do this you use the state of the art framework called Serverless Architecture. This will be nothing new to experienced web developer. If you create something on GoDaddy you get some code and you load it up. You configure a MySQL or NoSQL store or log file for data storage, and you just let it run.
Traditionally this has been the test and dev world for developers, and as soon as an application work it was often moved to a Enterprise hosting solution where a set of servers needed to be defined to run the different layers of the application. A coder who just wrote a bunch of code now had to think about breaking logic and data up to sit in layers, and the specifications for the layers. Other experts had to harden the servers and as you could now install .exe code people rushed to create add ons to give the servers better performance at the cost of vendor or even server lock in.
Well with Amazon products like Lambda for storing code logic, S3 Object storage to create scalable storage without servers, and DynamoDB, Redshift and RDS you can build a scalable solution without ever defining the servers.
Yes servers still exist, but it is AWS that worry about the servers. You also have the added benefit that no one on the planet can connect the servers running and the code you have created. This provides great deal of security as human attacks on the server farm can't get your stuff, or even find it.
Personally I think the best part of Serverless design is that experienced web developers will have to learn next to nothing. All the AWS tools are easier to use than the alternative server based solution. Coders can concentrate on defining the logic, the data and being sure that the solution is responsive enough by design. AWS will provision new CPUs and SSD as needed, you won't even see it.
This is far cheaper and easier to maintain than legacy systems that sit on boxes.
And what is the negative, well there is a degree of vendor buy-in with deploying systems this way that does not happen when you install code on VM in the Cloud running standard OSs.
I personally am not so worried about his because as the effort to create new code becomes shorter Enterprises will do what web developers who hosted on IPs will have done long ago, develop quickly and make solutions that are easy to migrate. Also with the expanding pace of digital transformation the life-cycle of any bit of code will start to be shorted than your hosting agreements with AWS.
There are some political issues to worry about. As a manager you have to be a bit more aware that certain people might not be comfortable with change. Don't ask an assessment of server free design from the people's who make a living hardening servers, they will find everything wrong with it.
Rather it might be smart to start building your team around security, architecture, code and UX; with the traditional role of networks and infrastructure being reduced over time.
You should start reducing the time an effort between a desire in your staff and a tool. Everyone sort of becomes a developer. You don't have to wait 6 weeks to get some boxes built or permission to expand the VM estate, you just press some buttons.
Make sure that when you start you have an empowered Serverless team with a budget, they need to be able to say yes to things. They also need to be fail first and fail fast kind of people as you don't have to buy expensive servers to try something.
So what is it all about?
Well after telling the Why now its time for the what.
Put simply, server-less is building your solution bases on SaaS or PaaS elements rather than hosting them on Virtual Machines.
So for example if you have some code you want to run in a web server in the Cloud. The dumb thing to do is to by a Instance of EC2 the size you need and load the code on to that. It cost more and you have to do a great deal of configuration. Using Containers like Docker reduce the cost but you now have to manage a container service and still manage you containers as you would on-premise.
If you know AWS you might think to deploy your code in Elastic BeanStalk, which is a better option. You can store you persistent code on cheap Object S3 storage rather than EBS, and you only start up tiny web servers when the code is needed. But still Elastic Beanstalk will create load balancers, EC2 instances and S3 for you, and if you solution is not well written or heavily used you may end spending the same as just hosting it on EC2 with EBS attached storage.
Rather load your code up to Lambda. you create a Lambda function, define the underlying engine and provide the code directly to it along with instances and interfaces.
For front ends the user needs to face rather than creating conplex server side pages create HTML 5 pages with JavaScript. If you call WebSockets to call your Lambda functions via an API gateway. This way you can store you site on S3 Object storage. Data can be stored on PaaS like DynamoDB, Redshift or RDS.
So there is you have it, fairly
No comments:
Post a Comment