Hi Dale, We can have couple of improvement with your suggestions. Please see in-line comments;
On Wed, Oct 9, 2013 at 6:49 AM, Sanjiva Weerawarana <[email protected]>wrote: > Hi Dale, > > On Tue, Oct 8, 2013 at 9:37 PM, Chalfant, Dale (DTI) < > [email protected]> wrote: > >> Team:**** >> >> ** ** >> >> Some things to consider for long-term roadmap:**** >> >> ** ** >> >> **** >> >> System documentation (such as system diagrams / deployment diagrams) go >> into repository (ideally an ITIL configuration management database/CMDB). >> This information is used along with rules to form build scripts. Certain >> instances are hibernated for quick startup (higher cost than building from >> scratch, but lower cost than active). >> > > This is an interesting next step definitely. We currently have a CMDB too > - that the manager writes to - but its fairly rudimentary yet. Right now we > are dealing with atomic service deployment only I believe. The next step is > to have a composite model that takes an entire system and deploys it as a > whole. Lakmal can you clarify what we can do in that regard right now - in > terms of inter-cartridge dependencies etc.. > > My suggestion is to do this improvement (support for composite apps - > that's where even specs like CAMP come in) next. We had some some for CAR > (WSO2's composite application archive) format but I'm not sure what status > its in. > Yes, as Sanjiva said we have composite application creating in our roadmap. We had quick looked for CAMP, but not in detail. Anyway we need to have capability of composite application creation. May be we can used ITIL and CMDB for that. [image: Inline image 2] We can include composite application engine with SM. Based on users requirement of their application, it will regenerate/list-out required cartridges+policies for the application. May be this will go with SM new GUI design. If we have resources (developers) we can start this as a parallel item and later integrate. > > Metering is performed on the boxes and we balance resources based on >> acceleration rather than some threshold. If a box is running 95% CPU and >> has been doing so for a while, that is a good thing, not an indicator of >> needing another box per se, but if the box is at 5% then quickly is >> climbing (high acceleration), we would want to fire up a hibernated box and >> get another in the pipeline. >> > > Yes +1. This is easily implementable in the proposed new architecture - > basically a CEP query which says if the rate of change of system load stays > at 5% over a few minute interval then fire up another one type query. Great > point that rate of change is more important than the actual current load. > Yes, this is exact use case, and one reason of introduce new architecture. With the cartridge heath publisher, we can get CPU load, load average, memory usage ..etc and based on one or all of them CEP will send summarised health message and based on that autoscalar take the decision. Also as you said, based on policy user has selected, if application need to switch new instance quickly and load balance, from Could controller we can have hibernated instances and update topology based on autoscalar decision, then load balancer can add ready-made members in very short time. > > Sanjiva. > -- > Sanjiva Weerawarana, Ph.D. > Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/ > email: [email protected]; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1 > 650 265 8311 > blog: http://sanjiva.weerawarana.org/ > > Lean . Enterprise . Middleware > -- Lakmal Warusawithana Software Architect; WSO2 Inc. Mobile : +94714289692 Blog : http://lakmalsview.blogspot.com/
<<composite-app.png>>
