It is mentioned that AWS Serverless Application Repository is in preview mode, I want to use it for publishing my live users. So my questions are: 1. Is preview mode means AWS Serverless Application Repository is in beta mode? 2. As it is in preview mode, How much it's support is reliable?
Preview Mode means that you need to apply to use the service. Amazon will ask you for your intended use case and why you want to use the service in advance of general availability. I do not recommend using preview services with live customers, only for internal testing. There is no real answer if its support is reliable - that is one of the purposes of preview mode.
Related
I want to get the deployment method using Powershell for Self-Hosted Integration Runtime.
The requirement is to track whether the SHIR is installed using "Powershell" commands Or its done through the Azure Portal by a human user by manual steps.
Is there any Flag in Azure which indicates the method of the resource deployment? i.e. if its a PowerShell/ARM template/Portal deployment?
Self-Hosted Integration runtime is a service installed on a windows operating machine (the only OS supported now) either on cloud(VM) or on-prem. Closest you can get to its details is under Applications and Services Logs on system Event Viewer, here you can Filter Logs for timestamp between Start and End of your ADF Pipeline.
Additionally, if you feel this is not helpful, you can share your Feedback so the product team can look into this idea. ✌
I wanted to Automate the Cloud Console on-premis Deployment process. I see two options to deploy the services using anypoint-cli or Rest API. Can some one please let me know what are the differences between them and which one should i choose(In terms of long term support) ?
Anypoint cli is a command line tool to interact with the REST API. It might not provide access to every endpoint of the API.
Using the API directly requires that you make the API requests in some programming or scripting language.
You should choose the one that makes more sense to you, and your use case. That can not be determined here.
As part of our pipelines, we currently use a deployment tool that has connectivity to our various instances and we can upload revisions/versions of our app to a central repository, archive them, and redeploy them at any time. Is Spinnaker intended to replace an existing deployment automation tool (there are many on market today) or is more meant for us to create pipelines that call the API of our other tool(s) when actually deploying our code to different servers?
Spinnaker has native support for deployment to supported cloud platforms (AWS, Google, CloudFoundry, and soon Azure).
In those environments, the Spinnaker model is an immutable infrastructure style deployment where new VMs are created to push new software versions.
If that fits your needs, then Spinnaker could replace an existing deployment automation tool.
If that doesn't fit your model, then Spinnaker also supports calling out to an external execution environment as a pipeline stage (currently Jenkins is well supported) where you could implement custom behaviors to integrate to an existing deployment tool.
I'm trying to build a small webapp that will handle our development environments located on an openstack infrastructure (version 2012.2.2-dev, bundled in ubuntu 12.04) and I need to create some volumes using the API (i decided to use openstack rest api). I'm able to start machines and do some other operations (everything is built based on this: http://api.openstack.org/api-ref.html). If I send the request to create a volume as explained on the api reference, i get a 404. I tried different api versions (v1), but still no success.
Thank you in advance.
What language are you coding in? You could just use an SDK for this and skip trying to talk to the API directly. See
https://wiki.openstack.org/wiki/SDKs
In newer releases of OpenStack it is preferable to make use of the Cinder API rather than Nova API.
In folsom, Cinder uses IDENTICAL API refs to Nova volume related API sets. This is because this was the first release to separate out volume management to cinder as a stand alone project. While volume API references remain in folsom it is not the default and it is not the preferred method for accessing volumes REST queries.
Check out.
http://docs.openstack.org/developer/cinder/
I have a question about whether cloud vendors have an inter-operable mechanism. For example, I am developing a WCF service and hosting in Azure successfully. After a pro-long time using Azure, can I use the same code for deploying it in AWS? Will it be possible? Does the API of both matches the same for deploying? If not, what are all the extra care needed for hosting the same service when switching over other Cloud Vendors like Salesforce.com, OpenStack, etc.,
In general, you can't just take what you develop for one Cloud platform and put it on another: they have different functionality sets and expose different APIs. However, the more low-level you make your code, the more likely it is that you'll find another vendor with a very similar API, since virtualizing infrastructure is simpler (and closer to standardized) than virtualizing a CMS application.
If you're using just IaaS, you can probably port fairly rapidly but you have to do more work to make your application. If you're using PaaS (or SaaS!) then you're more locked-in but you get more support for developing rapidly: it's that support platform which is both the value-add and the lock-in, and you won't get one without the other.
If you're using an Azure web role for hosting your WCF service then from deployment point of view you will not have many problems with AWS. You'll simply use facilities offered by AWS SDK for .NET (aka Publish to AWS CloudFormation). For sure you'll have to change the logging part if you've used Azure Diagnostic and alla Azure services with related AWS services. We did this multiple times in the last year and it works.
For worker role it's not so simple because in Azure they are easily deployed like web role, but in AWS you haven't direct deployment from Visual Studio so you have to do some manual work using Windows Services or something else