It’s simple to use
Just Plug in your numbers for the racks and the server types and click evaluate button…and the output table populates with the result if the solution is possible
Got more racks and server types… Just add them and then click evaluate…
If the solution is not possible then you would get a solution not feasible error message….
Being the first version and made in a day, it is bound to have some bugs… Do Please report the bugs by raising an issue in https://github.com/julianfrank/dcplanner…
If you like it Please do Star this project in github…
Thanks & Enjoy!
I’ve been looking at entries in my diary I had made during college days and some interesting ideas popped up in terms of how future enterprise apps could look like. But first lets start from where we are right now
It is believed in common parlance that all enterprise apps are monoliths. This however is not true and many orgs that I happened to work with in the start of my career (early 2000s) had already split their software stack into layers and modules irrespective of whether the interconnection mechanism was SOAP or just plain old file transfer! However the individual application services were still carefully managed in dedicated servers.
Virtualisation fuelled with the Boom in Web Standards has now made the concept of Services Oriented Architecture a norm rather than an exception. Now the services are being maintained in dedicated environments but can be easily moved around (relatively) fast with minimal downtime. Cloud and PaaS have further made it relatively easy to distribute the services across geographies and service providers. Server-less is the latest buzzword which works great for IOT boom and uni-kernel infrastructure architectures that are slowly but steady being implemented by service providers.
The Future (IMHO)
I believe that the next trend would be to make the services themselves to be self aware, universally discover-able and self portable! Let me explain these one by one:
The Applications will be built to know their life and need in the system. They would also have security systems in place to let them realise if they are operating in the right location or not -AND- if they are servicing the correct service/humans. They would also have a distributed block-chain inspired credit system that will be used to decide if they need to remain active or self-destruct!
The Security Standards already are being redesigned to be universal instead of being perimeter limited. The same will extend to make the services themselves to be discover-able much in the same way we humans are slowly moving into using National-ID Card systems. It goes without saying that they would have some mechanism to disappear and replicate without causing confusion in the system as well! Bottom line if I create a software service and it needs a service then it would be able to discover and setup a contract to perform the service.
My Service would have compute credits that would be shared with the service I call to perform my services! Once Credits are over my service would self-destruct! But during its lifetime it would move across “certified” Cloud Domains and make itself available where necessary and leaving replicas to ensure distributed services.
This is not new ideas really, but just a bad actor being used for good purposes…. I’m referring to the lightweight viruses that for decades have been travelling and replicating across computers including mine two decades ago wiping out my programs… AaaaaW how I hate viruses!
Anyway they gave me some ideas to write about this week… Lets see if these come true!
Its Pongal 2018! Feels good after trying out Veshti… That too the non-Velcro type. Getting to get a few trees planted was a bonus. Sadly both these ventures are in their infancy and took my thoughts back to the IT world in terms of the Multi-Cloud pitch which is now slowly showing signs of maturing into a practical architecture.
I’ve always prophesied that the future of cloud is Peer to Peer Multi-Cloud and has always been an aspiration ever since the ‘cloud’ got popularized. The first use-case that came to my mind was the capability to port application/services across different service providers, geographies and partners. However IMO we should looks at more parameters to truly evaluate how things ave been changing and what does the future hold for us! Here is an CLOAKS based attempt:
- Number of vendors that support the architecture exact same stack
- Number of locations the Infrastructure Architecture can accommodate for the provided Applications
- The Level of Openness in the individual specifications
- Readiness of Applications to make full use of the Multi-Cloud Architecture
- Appreciation of the heavy duty impact of the CAP implications in Application Design considering the multi-cloud scenario
- Maturity of Security of in-scope workloads for both data at rest, in motion, in compute, identity, policy and control of data leak.
Its been at least 5 years but maturity across all these capabilities has not been truly demonstrated even close to my expectations. However there is good news as we are seeing things changing in the right direction and I believe it would be interesting to look at these evolving in different ages as below:
Age 1) Service Provider defined
This is something that became practical with AWS and Azure IaaS workloads providing network peering with on-premise workloads. Further multi-Region Networking is provided to handle movement of workloads within the same provider 😉
Age 2) Platform Vendor Defined
We are currently in this age with Vendors provided solutions that let enterprises scale their applications between their on-premise data-center and the cloud. the VMware Cloud solutions for AWS and Bluemix are a step in the right direction but still restricted to and supported between the same Platform only. There is still a lot to happen in this space this year and only time will tell what other vendors have in store!
Age 3) Community Defined
This I believe is the future and will be built by communities of like minded technocrats and disrupted by some new player who will force the cloud biggies to shut down the walls that they have built to discourage inter-operability between vendors and clouds.
Microsoft released the Azure Container Instance last week and unlike the rest of the container oriented cloud solutions in the market, this is a unique solution and I couldn’t resist trying it out. The Quick start guide in https://docs.microsoft.com/en-us/azure/container-instances/container-instances-quickstart let’s us experience how it can be utilized from the az-cli console bothe from the azure website and from the laptop. The rest of the tutorials also help understand how a standalone app can be packaged, loaded into the Azure Container Registry and the run inside the ACI.
So, what is this service….
To start with, it is basically Docker Linux Instances created on call and destroyed without the tenant having to invest in a fixed pool of virtual machines which happens to be the case with other Container Services. This is not the first time and there are other players in the market providing similar services (hyper.sh, now.sh etc.) where the customers can have their own Orchestration Infrastructure on Dedicated Infrastructure and utilise the Flexible Cloud Infrastructure that can scale from ‘0’ to …a very large number. Of course, there are the server-less services provided by the big three cloud vendors…but they happen to be very opinionated and short-lived on a per invocation basis. ACI on the contrary Gives the Server-less experience in an unopinionated way and perfectly ready for limited but long running services.
To enable this capability to be controlled by customer built orchestrators, Microsoft has already released the ACI-Connector (https://github.com/Azure/aci-connector-k8s)for Kubernetes. This connector runs as a container in the Local Kubernetes Infrastructure and proxies the requests to create and destroy containers as per the developer provided yaml. From my testing this was not working on the day of launch but got fixed on 4thAug2017…Works perfectly now…. I hope that in future this capability expands to other orchestrators and adds more features.
What would be good use cases for this?
Like similar Container PaaS services available this can be used to handle worker services which need more compute time than what the server-less services can accept. Otherwise with current pricing this is not a good candidate to replace always-on VM based services.