According to the ApigeeX documentation, there are 2-3 ways to operate an Apigee developer portal:
Apigee integrated portal
Drupal 9 modules
Do-it-yourself (DIY)
At the stage of introducing Apigee, I want to avoid the additional effort of hosting and maintaining an entire Drupal 9 instance, or the effort of developing a self-made portal.
On the other hand, I do not want to miss out on the opportunities the options 2 and 3 offer in the future.
Can I just seamlessly switch between the solutions, or potentially even run them in parallel? According to my research it seems as if all those solutions solely make use of the Apigee API, and do not store developer data, keys, credits, etc. in their own database, but it is hard to verify this.
Related
I am evaluating wep api gateway for my new projects. I used azure api gateway in the past. Reading about nginx as it is new and adopted by many. Can someone help me point out with some facts, pros, cons? Bug matrix will be a best help for me
Azure API Management is a mature and widely-used product, with many customers being very respected enterprises. Take a look at some public case studies.
It offers a very wide range of features, which are typical of an API management platform, and it is still being very actively developed. However, one of its biggest strengths lies in integration with Microsoft Azure services and features - multiregional deployments, virtual networks, monitoring and alerting solutions, native support for Service Fabric, Azure Function Apps and Azure Logic Apps, Azure Active Directory and others.
If you are considering hosting your new projects with Microsoft Azure, Azure API Management is a no-brainier.
The product is also one of the main reasons why Gartner named Microsoft a leader in the enterprise integration space.
Disclaimer: Although all of the above is best to my knowledge, I am affiliated with Azure API Management.
Although I have just started looking into this myself, here's what I can already conclude.
Looking at www.nginx.com/blog/deploying-nginx-plus-as-an-api-gateway-part-1/, Nginx requires a lot of manual configuration washed over many text files. That doesn't look flexible or effective, but I may have gotten a wrong impression.
Judging by how you're supposed to define your API keys using the map directive, Nginx API Gateway also looks like a new idea stretched on top of the existing product, while Azure API was designed for that exact purpose from the ground up.
Azure APIs, when published, come with auto-generated documentation and an interactive console that are in sync with all your updates.
With Azure API, you're putting all your eggs into one basket and completely depending on it's pricing and availability. At any moment Microsoft can increase their prices, or discontinue the product, and you cannot migrate elsewhere, at least not easily/quickly. At the same time, you can do your Nginx work once and run it on pretty much any server, starting with a low-end VPS or a Raspberry PI, if you'd like. It's pretty much yours.
I've been asked to develop a .NET web application with the following requirements and features:
Moderate software license expenses
.NET Web Application
Document storage (with change history, although a complete CMS is not needed)
Complex data model
Extensible and groupable object attributes
Private/public field visibility
Non-trivial relationships between database tables
Custom alert configuration (screen and e-mail notifications) about approaching due dates, missing documentation, etc.
Resource access control & user management (roles and groups)
High user volume (several thousands of users)
Many complex and dynamic forms
Search engine
Statistical reporting
Bulk data & metadata upload and download
Simple data migration
REST API for external integration
Multilanguage
Full-featured mobile version (for tablets and smartphones)
Corporate look and feel
These are the options I have considered:
SharePoint Foundation 2013 + Custom Web Parts + Custom DB + Document Libraries
Sense/Net + Custom Web Parts + Custom DB + Document Libraries
Custom ASP.NET Web Application
What approach would you recommend? Also, can you please make a recommendation on the following points?
Server characteristics and topology
Application architecture
Scalability
Search capabilities
Reporting tools
Persistence framework
Document storage (MS Office)
Mobility
First of all, I work for Sense/Net, which I want to put out there to be fair.
However, even if I wouldn't be, I'd still recommend looking at our solution based on the criteria you outlined. What you are planning to build seems to be really custom stuff and from experience, I can say that projects like this never changing. Going for an open-source application would definately be my choice, in order to make sure I don't hit a wall later down the line.
Sense/Net is practically capable of delivering everything you need out of the box, but of course, customization will be needed.
From a licensing perspective, you would also be better off probably, since we only lincense the CPU cores, not the thousands of users benefitting from the system.
Writing a custom application from scratch with these requierements would make no sense in my opinion as the costs would be well over the one of a readymade solution (whichever you choose).
The things need to be clarified are the reporting tools you will need and whether you need a native application for mobile devices (or would something working in their browsers would be sufficient).
I can see that this answer is well overdue, but if the topic is still of interest and you havent done so yet, drop us an e-mail through our website and we can help you out in finding the perfect solution!
I need to create an intranet portal in Drupal 7.
What will the required contributed Drupal 7 modules to accomplish a complete Intranet Portal.
The answer to this question will be different in each individual instance and will depend on the needs of the users.
Research the needs by speaking to the intended users, but don't ask them what they want. Instead, ask them about the problems they have. Ask which tasks they have trouble completing and find out the underlying cause. This will give you an idea of the applications they need.
Start with up to six of these problems and plan a schedule of work for the coming year with, say, quarterly releases. Develop a prototype and test it with your users. Listen to their feedback and continue to make improvements.
Don't think of this as a technology implementation, but as an ongoing process. You will find this helps with your stakeholder management: setting the six focus areas sets their expectations and listening to their feedback includes them in the process. This is valuable for adoption as you will spend less effort getting people onside since you already have advocates in place in the business.
platform: ASP.NET 4.5, MVC 4, C#
I'm currently designing a website that's available on the public domain. However, there is a meaningful % of my target market that would be uncomfortable putting some information on a public site, even if it's https etc.
What I'd like to be able to do is allow corporate users use my site, and one way to do that is to allow them to host my website on their intranet. The usual disadvantages are, of course, that they don't get their site updated as fast as the public one would, and it's also a headache for me in terms of support.
My questions are
What are some strategies to make "corporate friendly" deployments easy and hassle-free?
Are there ways I could keep the site public with just the database inside the intranet (can't see how... but then I'm no techno-know-all)
If I have no choice but to make it locally hosted - then what's the best way to do it to keep my development/support overheads at a minimum?
I hope the mods don't lock this. I'm asking for specific methods and technical approaches to a very real problem.
Thank you,
For #1, there's a many facets to the question. A couple thoughts that might help you think it out:
Deploying your app: Make it simple to deploy, and to upgrade, between versions of your application. Try to make it happen as a single operation, not upgrading different parts by hand manually. As Darin Dimitrov mentioned, you could look into a technology like Web Deployment Packages, especially with Visual Studio 2012 which will have incremental database publishing (in VS2010, the database was non-incremental so there wasn't really an "update" story). Keep the cost of deployment down so that they can afford to upgrade more frequently (not the cost of your product, but the overhead of who's getting paid to keep the system updated and running).
Consider differences between running on the Internet and on an Intranet: For example, authentication on the Internet is usually done with forms based authentication. On an intranet, you may want to consider supporting Windows authentication for a seamless login experience for corporate users. This should impact your designs to allow authentication to be modular between your deployments.
Corporate adoption of newer technologies might be slower than you want: You're using the latest and greatest (ASP.NET 4.5/MVC4). Some companies might not be prepared to deploy this now, or for a couple years. Consider if you could use an older, established technology, such as .NET 4 - having been out for a few years, it's already somewhat proven and has adoption.
For your 2nd question, it comes down to what their IT is willing to accommodate. Many corporate sites have the database within a secured LAN, but the web server is accessible from the public Internet. It's certainly a well-understood network design, but depending on the assets involved in your application, your customers may or may not agree to it. This one's a business decision.
For #3 the answer is common to any long term software project. It has to be high quality and maintainable if you want to minimize the hassle.
If you're only going to support the last N versions, make that very clear. Avoid supporting code that you're already fixed long in the past. Consider providing extra support or affordable upgrades to keep your customers on newer (and hopefully better) releases.
Keep in mind what components need to be upgraded between versions. Your web app (obviously), but also your database schema and any dependencies or libraries you're using. This is mostly the same considerations as #1. Make sure you have a good plan for upgrades and rollbacks.
Most importantly, test, test, test. Have functional regression tests and install/upgrade tests, and try out as many possibilities as you can think of.
Answer to only 1) above.
I would recommend a continuous integration tool. We use TeamCity and deploy mvc3 and mvc4 applications to our public as well as privately hosted sites with a click of a button. Previously, we used cruise control, but now we are more satisfied with TeamCity. Read up on them. Might lead you in the right direction.
You may checkout Visual Studio's Web Deployment Packages. They allow you to prepare a package that could directly be installed on your client's web servers.
I was reading this article Build Your First Cloud Application Using Visual Studio 2010 when It hit me:
Why would I switch from my normal
hosting (shared account, VPS, or
whatever) to host it on cloud
servers ?
Do I have to build my website with
ASP.NET Cloud Application to be able
to host it with any cloud providing
service company ?
How can I edit my ASP.NET Web
Application to be an ASP.NET Cloud
Application ?
Those are the questions I thought would help to gather a full picture about this new technology and it's own application template! but please feel free to add more points to consider in the answers.
Edit
so beside the difference in implementing a website between Azure and other cloud server
is there is a performance difference or any other differences between Azure and the other cloud servers ?
I didn't quite get what you meant by "bringing your app on site with your own staff may become more economical"
the Azure pricing are high and requires a whole new dedicated project to work with it restrictions. so both the hosting and the development are costy
I hope if there's any article about the good cloud hosting out there and perhaps any articles about the user experience (a legitimate review and maybe yours if you have any)
First, I believe "cloud" in the context of the blog article you read should really be more granularly defined as Azure. There are several cloud solution offerings and Azure is only one although it is gaining immense popularity in the MS community space. The Azure cloud is fairly unique compared to products like Amazon's cloud in that it requires applications that use it to comply to a specific set of APIs. To build an application for azure requires you to embrace certain architectural principles from the beginning and to build your app using its web and worker roles. To "fit in" to these roles, your app must be built within a special VS project that references the Azure SDK.
If you were to use another cloud solution like Amazon, it is more similar to firing up a VM or group of VMs that can host your app as is without the constraints of specific APIs. You simplu would fire up a windows server instance, install what you need on it like any other server you would use in a hosted or or leased data center environment.
I am not implying that the azure solution is flawed or overly restrictive. Rather, I think it supports some architectural constraints that will allow you to "fall into the pit of success." However, it may be difficult to effortlessly migrate many brown field apps to azure without making significant changes.
As far as why host a application in the cloud as opposed to a normal hosted environment. It really depends on your app, your business/budget constraints and your traffic level. For many small, hobby sites, you may be better off keeping your app on a traditional hosted environment. For larger scale apps, the cloud begins to make more sense. The cloud is really supporting a "pay per use" model. If you need to have the ability to scale out quickly without the funds or the ability to wait on a purchase of lots of additional hardware, the cloud is a good option. Cloud providers have deep pockets and plenty of server resources and bandwidth to send your way at a moments notice that you can rent instead of buy.
Also, because cloud providers are large and typically highly reputable, they can afford to hire expert staff and follow best practices that you may not be able to afford on your own. They can and will handle a lot of the day to day ops administration enabling you as a developer to not have to think of things like security and redundancy.
So as I see it, cloud solutions are ideal for apps that are beginning to see a fair amount of traffic, need guaranteed up time, and do not want to pay or bother themselves with their own admin staff, server purchasing and data center management. I think they are not practical for many small hobby sites and once you become really big, bringing your app on site with your own staff may become more economical.
That all said. it has become "cool" in the .net space for any site to run on azure. I'll admit that some of the architectural models are interesting and seem fun to work with. However, if you take a close look at the pricing model, you may find you are better off with your hosted plan.
Moving your .NET application to a cloud or hybrid infrastructure allows you to start evolving to a Microservices Architecture, with the ability to phase in Containers and a Serverless architecture.
You mentioned that Azure costs are high and maybe cumbersome in your situation.
Maybe consider other popular cloud providers like AWS. They have a ton of vendors and services all readily available to help make the adoption easy, in fact over 57% of Windows workloads currently run on AWS.
Here is an eBook we recently published about this exact topic.